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~^-^>Th1s  report  presents  the  results  of  the  IAS  Architecture  definition 
process  for  the  mid-term  (1984-88).  The  mid-term  definition  process  was 
directed  toward  the  definition  of  an  overall  top-down  system  architecture 
and  the  definition  of  new  system  elements  required  to  support  this  archi- 
tecture. 
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EXECUTIVE  SUMMARY 

Commencing  with  Its  appointment  by  OSO/DTACCS  (now  ASD/C3I)  In 
early  197S  as  tho  AUTODIN  System  Manager,  the  Oefense  Communications 
Agency  (OCA)  has  had  responsibility  for  development  of  an  Integrated 
AUTOOIN  System  Architecture  (IASA),  The  purpose  of  the  IASA  Is  to 
guide  the  evolution  of  the  Oefense  Communications  System's  AUTODIN 
subsystem  towards  a more  secure,  accurate,  survlvable,  and  efficient 
means  of  message  processing  and  data  communications  while  offering 
standard  solutions  to  user  requl rements . The  IASA  1$  organized  Into 
three  architectural  descriptions  corresponding  to  the  three  major 
time  periods  In  the  evolutionary  development  of  an  Integrated  AUTOOIN 
System: 

Near-Term  (1978-1983)  • Initial  Implementation  of  the 
AUTOOIN  II  packet  switched  data  network  and  consolidation 
with  the  existing  AUTOOIN  I narrative/record  message 
switched  network 

Mid-Term  (1984-1988)  • expansion  of  the  AUTOOIN  II  data 
service  worldwide,  closure  of  AUTOOIN  I ASCs,  Introduction 
of  standardized  terminals,  full  Integration  of  AUTOOIN  I 
and  II 

Far-Term  (Post  1988)  - complete  Integration,  narrative/ 
record  and  data  service  worldwide,  continued  evolution 
toward  the  third  generation  DCS. 

Presented  In  this  report  are  the  results  of  the  IAS  Architecture 
definition  process  applicable  to  the  Mid-Term.  Previous  effort  In 
this  process  was  directed  toward  Identification  and  analysis  of  Imple- 
mentation alternatives  for  the  Near-Term  (1978-1983).  The  Near-Term 
work,  described  In  the  IAS  Architecture  Report  of  December,  1977, 
was  Intended  to  shape  decisions  on  the  Implementation  and/or  use  of 
existing  and  readily  available  hardware/software  components  In  order 
to  achieve  a Near-Term  capability.  The  Mid-Term  architecture  analyses, 
by  contrast,  were  directed  toward  the  development  of  an  overall,  top- 
down  system  architecture,  and  the  definition  of  new  system  elements  re- 
quired to  support  this  architecture. 

Presented  herein  are  the  preferred  architecture  for  the  Mid-Term, 
two  alternate  architectures  and  a description  of  the  process  and  ra- 
tionale for  selecting  the  preferred  architecture.  In  addition,  a pro- 
posed transition  approach  to  achieve  the  preferred  architecture  and  to 
Identify  the  actions  required  to  evolve  from  the  Near-Term  IAS  Archi- 
tecture of  1983  to  the  Mid-Term  IAS  architecture  of  1988  Is  described. 

In  addition,  this  report  Includes  guidance  In  planning  and  programing 
for  a new  family  of  terminals,  and  other  hardware/software  components  of 
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Btstd  on  AS0(CJI ) guidance  and  overall  AUTOOIN  system  requirements 
the  major  architecture!  objectives  relevant  to  the  Mid-Term  are: 

Expend  AUTOOIN  II  to  provide  a worldwide  data  backbone 

Complete  phase-out  of  AUTOOIN  I switches 

Standardize  termlnals/AMPEs 

Reallocate  ASC  functions  to  other  IAS  elements 

Enhance  system  survivability 

N. 

Enhance  tactical  and  allied  forces  Interoperability  with  OCS 

Accomplish  the  above  objectives  via  evolution. 

Consistent  with  these  objectives,  the  IAS  Architecture  definition 
effort  over  the  pest  year  has  been  directed  toward  the  following 
objectives: 

Define  viable  candidate  architectures  for  the  Mid-Term 

Recommend  a preferred  Mid-Term  Architecture  for  the  IAS 

Evaluate  the  differences  between  the  preferred  architecture 
and  viable  alternatives 

Define  an  approach  to  transition  from  the  Near-Term  IAS  to 
the  Mid-Term  IAS. 

The  process  of  defining  the  Mid-Term  Architecture  for  the  IAS  was 
constrained  to  consider  only  those  architectural  alternatives  which  are 
technically  and  economically  feasible  within  the  Mid-Term  time  frame, 
consistent  with  the  objectives  of  the  Integrated  AUTODIN  Systera 
Architecture,  and  finally,  consistent  with  the  evolutionary  philosophy 
of  the  Integrated  AUTOOIN  System.  The  principal  constraints  on  the 
architecture  definition  process  were  the  following: 

Current  AUTODIN  I Inventory  assets 

Current  AUTOOIN  II  development  status 

Inter-Service/Agency  Automated  Message  Processing  Exchange 
(I-S/A  AMPE)  program  status 

Available  technology. 

For  the  Near-Term,  architecture  definition  was  issue  oriented  and 
addressed  specific  options  available  to  the  system  Implemented  The 
architecture  definition  process  In  support  of  the  Mid-Term,  on  the 
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other  hand.  Is  considerably  broader  In  scope,  and  Is  aimed  toward 
definition  of  a top-down,  overall  architectural  description. 

The  approach  to  defining  the  Mid-Term  IAS  Architecture  was 
based  on  the  following  three  analysis  efforts. 

Definition  of  Mid-Term  requirements  and  operating 
envl ronment 

. Generation  of  candidate  architectures  and  selection  of 
alternative  architectures  from  among  viable  candidates 

. Evaluation  of  alternatives  and  selection  of  a preferred 
architecture. 

The  definition  of  Mid-Term  requirements  and  operating  environ- 
ment Involved  the  projection  of  IAS  Input  traffic;  the  projection  of 
AMPE  and  I-S/A  AMPE  populations;  the  Identification  and  definition  of 
required  IAS  services  and  functions;  and  the  Identification  and 
definition  of  candidate  Mid-Term  network  elements. 

Candidate  network  elements  for  the  Mid-Term  IAS  Include  those 
elements  of  the  Near-Term  IAS  architecture  that  can  be  retained 
through  the  mid-term  as  well  as  new  elements  that  could  be  developed 
In  time  for  the  mid-term.  The  candidate  IAS  elements  and  their 
characteristics  are  the  following: 

. Packet  Switch  Node  (PSN).  The  PSNs  Installed  In  CONUS 
and  overseas  under  the  AUTODIN  II  program  will  be  avail- 
able In  the  mid-term  time  frame  for  use  In  the  IAS 
backbone.  Based  on  current  traffic  projections,  the 
PSNs  Installed  in  the  near-term  should  be  sufficient  to 
accommodate  the  total  IAS  busy  hour  traffic.  The  need 
for  additional  PSNs  to  be  Installed  during  the  mid-term 
In  order  to  support  expansion  Into  the  far-term  and/or 
growth  In  the  network  will  be  based  upon  user  acceptance 
and  experience  with  the  Initial  operational  network. 

. Automated  Message  Processing  Exchange  (Near-Term  I-S/A 
AMPE,  AMME,  IOMX/NAVCOMPARS , AF  AMPE,  Streamliner).  Most 
of  the  MILDEP/Agency  AMPE  equipments  will  reach  the  end 
of  their  useful  service  life  during  the  mid-term  and  will 
be  replaced  by  standardized  Inter- Service/ Agency  AMPEs. 
The  MILDEP/Agency  AMPEs  are  therefore,  not  considered 
principal  network  elements  for  the  Mid-Term  IAS.  (Those 
MILDEP/Agency  unique  AMPEs  retained  in  the  mid-term  will 
be  treated  the  same  as  other  large,  automated  AUTODIN  I 
terminals  In  the  IAS). 
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AUTOOIN  Switching  Center  (ASC).  A principal  objective  of 
the  Mid-Term  IAS  Architecture  Is  the  closure  of  the  exist- 
ing ASCs  both  In  CONUS  and  overseas.  Therefore,  ASCs  will 
be  retained  In  the  Mid-Term  IAS  Architecture  only  as 
required  to  facilitate  smooth  and  orderly  transition. 

Central  Service  Facility  (CSF).  The  CSF  Is  a postulated 
new  centralized  network  service  element  that  would  perform 
necessary  user  support  functions  and/or  network  functions 
to  accomplish  message  delivery  and  provide  needed  user 
services.  The  CSF  is  accessed  via  the  backbone  network 
and  does  not  directly  terminate  subscriber  equipments. 

The  specific  functional  capability  of  the  CSF  Is  dependent 
upon  the  architectural  alternative  selected. 

Inter-Service/Agency  AMPE  (I-S/A  AMPE).  This  new  element 
Is  postulated  as  a standardized  replacement  for  the  exist- 
ing MILDEP/Agency  AMPEs.  It  would  provide  a complete  set 
of  agreed  upon  common  Service/ Agency  AMPE  functions  and 
have  provision  for  acconmodatlng  a limited  number  of  user 
unique  functions.  The  I-S/A  AMPE  will  be  modular  In  both 
hardware  and  software  such  that  great  flexibility  will  be 
available  to  the  Services  and  Agencies  In  tailoring  the 
I-S/A  AMPE  for  each  Installation.  The  basic  functional 
capability  of  the  I-S/A  AMPE  Is  essentially  Independent 
of  the  architectural  alternative  selected. 

Enhanced  Inter-Service/Agency  AMPE  (I-S/A  AMPE(E)).  This 
new  element  Is  postulated  as  a network  service  element 
that  will  be  derived  from  Installed  I-S/A  AMPEs  through 
modular  expansion  of  software  (and  If  necessary  hardware). 
The  I-S/A  AMPE  would,  therefore.  Include  all  of  the 
functions  of  an  I-S/A  AMPE  as  described  above,  and  replace 
a normal  I-S/A  AMPE  In  the  network  at  selected  locations. 
However,  the  enhanced  I-S/A  AMPEs  In  the  network  would 
also  provide  the  additional  network  functions  needed  to 
allow  phase-out  of  remaining  ASCs  and  provide  new  network 
functions.  The  I-S/A  AMPE(E) , like  the  I-S/A  AMPE,  will 
be  modular  and  thus  provide  the  Services  and  Agencies 
great  flexibility  In  tailoring  the  I-S/A  AMPE(E)  to  meet 
site  requirements.  The  full  functional  capability  of  the 
I-S/A  AMPE(E)  depends  on  the  architecture  alternative. 

Common  Family  of  AUTOOIN  Terminals  (CFT).  A new  family 
of  terminal  equipments  Is  being  defined  by  DCS  as  part  of 
the  IASA  program.  This  common  family  will  Include  a full 
range  of  terminals  from  simple  teletypewriter  to  highly 
automated  user  terminals.  The  functional  capabilities  of 
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these  terminals  will  be  defined  on  the  basis  of  user  requi- 
rements and  are  Independent  of  the  architectural  alternatives 
selected. 


It  should  be  noted  that  not  all  of  the  candidate  architectural  elements 
are  utilized  In  all  architectural  alternatives.  In,  addition,  the  roles 
of  some  elements  are  dependent  upon  the  architectural  alternatives  In 
which  they  are  used. 

The  set  of  candidate  architectures  was  generated  through  a 
sequential  decision  tree  approach  based  on  three  major  architectural 
decision  levels: 


Selection  of  a network  element  set  from  among  the  available 
candidate  elements 


. Allocation  of  functions  among  the  selected  element  set 

. Consideration  of  specific  conflquratl on/connectivity  options 
within  the  architecture  (e.g. , dual/single  connection  of 
nodal  elements). 

The  candidate  definition  process  resulted  In  the  Identification 
of  23  candidate  architectures.  Further  analysis  reduced  this  set  to 
three  final  alternative  architectures.  All  three  alternatives  utilize 
the  packet  switched  node  (PSN)  as  the  principal  backbone  switching 
element  and  the  Inter-Service/Agency  AMPE  (I-S/A  AMPE)  as  the  principal 
access  area  message  processing  and  communications  concentrator  element. 
The  basic  characteristics  and  distinctive  features  of  the  three 
candidates  are  summarized  below: 


Alternative  I - This  alternative  represents  a centralized 
architecture  with  little  or  no  hierarchical  structure  In 
the  access  area.  All  network  and  user  services  In  this 
alternative  are  provided  from  a relatively  small  number  of 
service  elements  connected  to  the  backbone  and  accessed  via 
the  network.  These  service  elements  are  the  Centralized 
Service  Facilities  (CSF) 

Alternative  II  - This  alternative  represents  a distributed 
architecture  In  which  user  and  network  services  are  provided 
from  a common  access  area  element,  the  enhanced  I-S/A  AMPE 
(I-S/A  AMPE(E)).  This  results  In  a very  flexible  structure 
In  the  access  area  with  services  accessed  both  directly  and 
via  the  backbone  network.  In  addition,  this  architecture 
provides  the  maximum  degree  of  commonality  among  network 
elements. 


Alternative  III  - This  alternative  represents  a hybrid 
architecture  between  the  centralized  structure  of  Alternative 
I and  the  distributed  structure  of  Alternative  II.  In  this 
architecture,  some  services  are  provided  by  a centralized 
backbone  service  element  (the  CSF),  and  the  remaining  services 
are  provided  by  a distributed  access  area  element  (the  I-S/A 
AMPE(E)). 

Each  of  these  architectures  provides  the  required  Mid-Term  IAS 
services  and  functions,  and  Is  consistent  with  the  constraints  and  ' 
anticipated  operating  environment  of  the  Mid-Term. 

In  order  to  select  a preferred  Mid-Term  IAS  Architecture,  the 
three  alternative  architectures  were  evaluated  with  respect  to  both 
technical  and  cost  factors.  This  evaluation  was  based  on  a series 
of  quantitative  and  qualitative  technical  analyses  performed  In 
support  of  the  IAS  architecture  definition.  The  major  evaluation 
criteria  used  In  these  analyses  are  the  following: 

Operational  effectiveness 

Flexibility 

Surv 1 vab 1 1 1 ty/Ava 1 1 ab 1 1 1 ty/Suppo rtabl 1 1 ty 

Transition 

Cost 

Based  upon  the  results  of  the  evaluation  process,  the  preferred 
architecture  for  the  Mid-Term  IAS  Is  Alternative  II.  This  alternative 
was  determined  to  be  preferred  to  each  of  the  other  alternatives  In 
three  of  the  five  major  evaluation  criteria  Including  the  two  technical 
criteria  which  are  considered  most  Important  for  the  Mid-Term  IAS  - 
transition  and  survlvablllty/avallablllty/supportablllty.  A principal 
characteristic  of  this  architecture  which  led  to  Its  selection  Is  the 
consolidation/ Integration  of  network  and  user  motivated  functions  into 
a single  service  element  based  upon  the  currently  planned  I-S/A  AMPE 
program.  This  consol Idatl on/ Integration  provides  significant  potential 
benefits  In  both  cost  and  performance,  and  contributes  materially  to 
the  ease  of  transition  from  Near-Term  to  the  Mid-Term  network  architec- 
ture. 

The  preferred  architecture  for  the  Mid-Term  IAS  presented  In  this 
report  meets  all  of  the  major  objectives  of  the  IAS  program.  In 
addition,  the  recommended  transition  approach  will  provide  an  orderly 
evolution  from  the  current  AUTOOIN  through  the  Near-Term  Into  the  Mid- 
Term  and  eventually  Into  the  Far-Term. 
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SECTION  I 
INTRODUCTION 


I.  PURPOSE 


The  Integrated  AUTOOIN  System  (IAS)  Architecture  Is  organized 
Into  three  architecture  descriptions  corresponding  to  ihe  three  major 
time  periods  In  the  evolutionary  development  of  an  Integrated  AUTOOIN 
System: 

o Near-Term  (1978-1983)  - Initial  Implementation  of  the  AUTOOIN 
II  packet  switched  data  network  and  consolidation  with  the 
existing  AUTOOIN  I narratl ve/record  message  switched  network 

o Mid-Term  (1984-1988)  - expansion  of  the  AUTOOIN  II  data 

service  worldwide,  closure  of  AUTOOIN  I ASCs,  Introduction  of 
standardized  terminals,  full  Integration  of  AUTOOIN  I and  II 

o Far-Term  (Post  1988)  - complete  Integration,  narrative/record 
and  data  service  worldwide,  continued  evolution  toward  the 
third  generation  DCS. 

The  Integrated  AUTOOIN  System  Architecture  Report  of  December, 
1977  Identified  Implementation  alternatives  and  recommendations  for 
the  Near-Term  (Reference  a).  This  report  presents  the  preferred 
architecture  for  the  Mid-Term,  identifies  two  alternative 
architectures  and  describes  the  process  and  rationale  for  selecting 
the  preferred  architecture.  In  addition,  this  report  describes  a 
proposed  transition  approach  to  achieve  the  preferred  architecture 
and  Identifies  the  actions  required  to  evolve  from  the  Near-Term  IAS 
Architecture  of  1983  to  the  Mid-Term  IAS  Architecture  of  1988.  The 
purpose  of  the  IASA  Is  to  qulde  the  evolution  of  the  Defense 
Communications  System's  AUTOOIN  subsystem  towards  a more  secure, 
accurate,  survlvable,  and  efficient  means  of  message  processing  and 
data  communications  while  offering  standard  solutions  to  user 
requirements. 

It  should  be  noted  that  the  IAS  will  neither  be  a new  system  to 
be  suoerlmposed  on  all  other  user  systems  In  a duplicative  way,  nor 
will  It  exploit  technological  advances  In  the  data  processing 
Industry  when  there  Is  no  well  defined  need  to  do  so. 

2.  BACKGROUND 

In  July,  1974,  the  General  Accounting  Office  (GAO)  published  a 
report  that  was  critical  of  the  Department  of  Defence  (DoO)  for  (1) 
not  having  a single  agency  responsible  for  management  of  the  entire 
AUTOOIN  subsystem  to  Include  AUTOOIN  terminals;  (2)  for  a poor 
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telecommunl cations  center  consolidation  record;  and  (3)  for 
duplication  of  effort  and  proliferation  of  AMPE-type  AUTODIN 
terminals  by  the  Military  Departments  (MILDEPs)  and  DoD  Agencies. 

The  GAO  recommended  to  the  OoO  that  a single  AUTOOIN  manager  be 
appointed  to  resolve  the  problems  as  they  surfaced. 

In  February.  1975.  OSD/OTACCS  (now  ASD(C3I))  acted  on  the  GAO 
recommendation  by  tasking  the  Defense  Communications  Agency  (OCA)  In 
coordination  with  Services/Agencies,  to  develop  an  Integrated  AUTOOIN 
System  Architecture  (I ASA)  on  a terminal -to- term  Inal  basis  and.  based 
on  that  archl tecture. to  define  a common  family  of  AUTOOIN  terminal 
hardware  and  software. 

On  12  December  1975,  OSD/DTACCS  approved  the  OCA  IASA  development 
plan  which  would  address  the  various  elements  (e.g.,  PSNs.  AMPEs, 
terminals,  etc.)  as  a single  Integrated  system  with  processing 
functions  allocated  to  system  components  on  the  basis  of  how  and 
where  they  can  best  be  performed.  As  a result  of  this  plan.  DCA  Is 
responsible  for  accomplishing  three  objectives:  (1)  a system 
architecture  on  a terminal -to- terminal  basis;  (2)  terminal 
specifications;  and  (3)  related  standards,  formats,  and  procedures. 

As  an  outgrowth  of  the  OSD  tasking,  JCS  Memorandum  of  Policy  165, 
titled:  AUTODIN  and  Associated  Message  Processing  Systems,  was 
Issued  on  5 May  1976.  MOP  165  established  AUTOOIN  as  the  DoD 
common-user  data  communications  system,  directed  maximum  use  of  the 
system  elements.  Identified  criteria  for  Interservice 
telecommunications  center  consolidation  and  automation,  provided 
safeguards  to  prevent  proliferation  of  non-standard  terminal  systems, 
and  provided  policy  and  guidance  for  use  of  new  equipments  using 
automation  techniques  through  the  AUTODIN. 

3.  ORGANIZATION 

The  IASA  Project  organization  is  shown  In  Figure  1.  Control  of 
the  project  Is  exercised  through  the  AUTOOIN  Systems  Integration 
Branch  (Code  534),  Headquarters  DCA.  Technical  Support  Is  provided 
by  the  Defense  Communications  Engineering  Center  (OCEC). 
Representatives  of  OCA,  MILDEPs.  National  Security  Agency  (NSA), 
Defense  Intelligence  Agency  (DIA),  and  Defense  Logistics  Agency  (DLA) 
are  formed  Into  a Technical /Pol Icy  Panel  which  serves  as  the  forum 
for  discussion  of  IASA  Issues.  In  addition,  there  are  three  working 
groups,  each  chaired  by  DCA,  with  participation  from  MILDEPs  and  DoD 
Agencies. 
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4.  IAS  ARCHITECTURE  OBJECTIVES 

Based  on  AS0IC3I)  guidance  and  overall  AUTODIN  system 
requirements,  the  major  architectural  objectives  relevant  to  the 
ml d- tens  are: 

o Expand  AUTOOIN  II  to  provide  worldwide  data  backbone 
o Complete  phase-out  of  AUTOOIN  I switches 
o Standardize  terminal s/AHPEs 
o Reallocate  ASC  functions  to  other  IAS  elements 
o Enhance  system  survivability 

o Enhance  tactical  and  allied  forces  Interoperability  with  OCS 

o Accomplish  the  above  objectives  via  evolution. 

Consistent  with  these  objectives,  the  IAS  Architecture  definition 
effort  over  the  past  year  has  been  directed  toward  the  following 
objectives: 

o Define  viable  candidate  architectures  for  the  mid-term 

o Recommend  a preferred  Mid-Term  Architecture  for  the  IAS 

o Evaluate  the  differences  between  the  preferred  architecture 
and  viable  alternatives 

o Define  an  approach  to  transition  from  the  Near-Term  IAS  to 
the  Mid-Term  IAS. 

In  addition,  specific  analyses  were  performed  under  this  effort  to 
address  the  following  additional  architectural  objectives /Issues: 

o Project  IAS  user  requirements  through  the  mid-term 

o Define  the  role  of  the  Inter-Service/Agency  AM PE 

o Define  the  role  of  the  Centralized  Service  Facility 

o Identify  the  Impact  of  the  Mid-Term  IAS  Architecture  on 
AUTOOIN  II  design  (PSN,  terminals,  protocols.  System  Control) 
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o Define  IAS  security  subsystem 

o Evaluate  options  for  expansion  of  AUTOOIN  II  overseas 

The  preferred  architecture  for  the  Mid-Ten*  IAS  presented  In  this 
report  meets  all  of  the  major  objectives  of  the  IAS  program.  In 
addition,  the  recommended  transition  approach  demonstrates  that  the 
architecture  can  be  achieved  In  an  orderly  evolutionary 
process  from  the  current  AUTOOIN  through  the  near-term  Into  the 
mid-term  and  eventually  beyond  Into  the  far-term. 

5.  SCOPE 

This  report  presents  the  results  of  the  IAS  Architecture 
definition  process  applicable  to  the  mid-ten*.  Previous  effort  In 
this  process  mas  directed  toward  Identification  and  analysis  of 
Implementation  alternatives  for  the  near-term  (1978wl983).  This 
near-term  work,  described  In  the  IAS  Architecture  Report  of  December, 
1977,  was  Intended  to  shape  decisions  on  the  Implementation  and/or 
use  of  existing  and  readily  available  hardware/software  components  in 
order  to  achieve  a near-ten*  capability.  The  mid-term  architecture 
analyses,  by  contrast,  were  directed  toward  the  development  of  an 
overall,  top-down  system  architecture,  and  the  definition  of  new 
system  elements  required  to  support  this  architecture.  This  report 
Is  Intended  to  provide  guidance  to  DoD  In  planning  and  programming 
for  a new  family  of  terminals,  and  other  hardware/software  components 
of  the  IAS. 

The  overall  IAS  program  milestones  are  identified  In  Figure  2. 

As  Indicated  In  this  figure,  the  mid-term  architecture  definition 
will  continue  through  FY  79  In  order  to  provide  necessary  functional 
specifications  for  the  Common  Family  of  AUTODIN  Terminals  to  Include 
the  Inter-Service/ Agency  AMPE. 
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SECTION  II 

GENERAL  ARCHITECTURAL  ALTERNATIVES  FOR  THE  MID-TERM  IAS 
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1.  the  NEAR-TERM  IAS  ARCHITECTURE  OF  1983 

In  order  to  evaluate  the  alternative  architectures  available  for 
the  Mid-Term  Integrated  AUTOOIN  System  (1984-1988)  It  Is  necessary  to 
understand  the  evolutionary  changes  In  the  AUTOOIN  I /I I networks  that 
will  result  from  Implementation  of  the  Near-Term  IAS  Architecture. 

It  Is  recognized  that  the  evolutionary  nature  of  the  changes  In  the 
AUTOOIN  I /I I networks  preclude  a single  point  description  of  this 
period  of  rapid  development  and  Implementation.  However,  for  purpose 
of  this  report  It  Is  useful  to  represent  the  cumulative  network 
changes  as  a single  description  referred  to  throughout  this  document 
as  the  Near-Term  IAS  Architecture  or  the  1983  Architecture.  This 
conceptual  single  point  description  of  the  Near-Term  Architecture  for 
the  Integrated  AUTOOIN  System  represents  a point  of  departure  for  all 
subsequent  mid-term  architecture  definition  efforts. 

a.  General  Description.  The  Near-Term  Integrated  AUTOOIN  System 
Architecture  will  result  from  evolutionary  developments  of  both  the 
existing  AUTOOIN  I narrative/record  network  and  developments  under 
the  AUTOOIN  II,  Phase  I packet  switched  network.  By  the  end  of  the 
near-term  (1983)  Interactive,  query/ response  and  bulk  data  service 
among  host  computers  and  a variety  of  terminals  will  be  provided 
through  a network  of  AUTOOIN  II  packet  switch  nodes  (PSN).  During 
the  near-term,  up  to  four  of  the  current  CONUS  AUTOOIN  I ASCs  will 
have  been  closed.  Common-user  narrative/record  service  to  all  DoD 
components  world-wide  will  be  provided  by  a network  of  MILDEP/  Aaency 
Automated  Message  Processing  Exchanges  ( AMPE)  and  terminal  equipment 
supported  by  the  remaining  ASCs  In  CONUS  and  at  least  seven  ASCs 
overseas  connected  via  a combination  of  AUTOOIN  II  PSN  backbone 
trunks  and  remaining  Inter-ASC  trunks.  Interface  between  AUTOOIN 
record/data  users  and  tactical /all led  users  will  be  accomplished  by 
designated  ASC  Interfaces  to  the  NATO  NICS  TARt  and  AN/TYC-39 
automatic  message  relays.  As  will  be  seen  In  subsequent 
descriptions,  the  fully  Integrated  end-to-end  common-user  network 
envisioned  for  the  Integrated  AUTOOIN  System  will  not  be  achieved  by 
the  end  of  the  near-term.  The  1983  IAS,  therefore.  Is  best  described 
as  a consolidated  DCS  subsystem  consisting  of  two  major  networks,  the 
AUTOOIN  I narrative/record  network  and  the  AUTOOIN  II,  computer 
communications  oriented  network.  The  IAS  Implementation  efforts 
throughout  the  near-term  will  result  In  a considerable  degree  of 
sharing  of  assets  between  these  major  networks  as  well  as  significant 
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standardization  of  ustr  terminals  and  local  message  processing 
equipments.  More  Importantly,  the  near-term  developments  will  lay 
the  groundwork  for  the  total  Integration  of  these  two  networks  that 
will  take  place  throughout  the  mid-term  time  period.  The  remaining 
paragraphs  In  this  section  describe  the  1963  Architecture  In  more 
detail. 

b.  Major  Subsystems  of  the  1963  Architecture. 

(1)  AUTOOIN  I.  The  Automatic  Digital  Network  (AUTODIN)  I Is 
a store- and- forward  switched  network  of  the  Defense  Communications 
System  (OCS)  which  functions  as  a single  Integrated  world-wide, 
high-speed,  computer-controlled,  general-purpose  communications 
network,  providing  secure  record  communications  service  to  the 
Department  of  Defense  (OoO)  and  other  Federal  agencies.  AUTOOIN  I 
has  been  operational  for  approximately  16  years  and  has  undergone 
numerous  enhancements  and  expansions  required  to  meet  the  growing  OoD 
requirements  for  data/record  communications.  In  addition,  several 
additional  enhancements  and  Improvements  are  currently  In  process 
and/or  planned  for  the  AUTOOIN  I to  keep  It  viable  and  responsive  to 
the  needs  for  narrative/record  communications  Into  the  1980s. 

CONUS.  An  expanded  memory  system  was  recently  Installed 
at  all  eight  CONUS  ASCs  as  well  as  at  the  Hawaii  ASC.  This  memory 
system,  which  consists  of  four  disc  units  and  two  mini -computers  at 
each  switch,  frees  up  core  space  for  additional  programs  and  provides 
faster  cycle  time  than  the  old  mass  memory  units.  The  new  software 
package  Included  with  this  system  will  also  allow  for  a larger 
operating  program  through  program  overlays.  Another  CONUS  AUTOOIN 
support  project  Is  replacement  of  the  magnetic  tape  and  mass  memory 
units  with  disc  units  at  each  leased  ASC.  In  addition  to  significant 
cost  savings,  this  enhancement  will  provide  a direct,  high-speed, 
channel  Interconnect  to  the  AUTOOIN  II  PSNs.  This  will  permit 
utilization  of  the  PSN  network  for  digital  trunking  between  ASCs. 

Overseas.  To  meet  currently  forecasted  operational 
requirements  and  to  replace/refurbish  worn  out  subsystems  of  the 
overseas  AUTOOIN  I,  OCA  has  also  Initiated  several  enhancement 
projects.  These  are:  memory-memory  control  replacement  program; 
Input/output  controller,  card  reader,  and  high-speed  printer 
replacement;  tape  subsystem  replacement;  and  patch  and  test  facility 
upgrade.  These  enhancements  will  Insure  operation  of  the  overseas 
AUTOOIN  through  at  least  196S. 


(2)  AUTOOIN  II.  The  AUTOOIN  II  Isa  general  purpose  data 
communications  packet  switched  network  for  Integrating  the 
teleprocessing  and  record  communications  needs  of  DoD  Into  a single 
digital  backbone  system.  AUTOOIN  II  Phase  I will  achieve  an  Initial 
Operational  Capability  (IOC)  In  FY  lgeo. 

CONUS.  The  design  of  the  AUTOOIN  II  system  Is  based  on 
packet-switching  technology  with  the  Intent  to  use  fully  those 
**P*€ts  of  the  ARPANET  design  technology  (such  as  proven  algorithms) 
that  are  applicable  to  the  new  system.  The  system  will  employ  a 
short  data  handling  unit,  or  packet  of  bits,  to  accommodate 
man-computer,  computer-computer  and/or  computer-terminal  data 
traffic. 


Each  AUTOOIN  II  packet  switch  (PSN)  will:  route  and 
distribute  packetlzed  traffic  (Interactive,  query/ response,  record, 
and  bulk  data)  over  a full  duplex  wl de-band  trunking  network; 
electrically  Interface  with  the  AUTOOIN  I system  through  CONUS  ASCs; 
terminate  up  to  150  lines  (both  Individual  and  multiplex)  per  switch 
with  a capability  to  service  up  to  several  hundred  data  subscribers 
and  accommodate  dial-up  access  lines  for  low  volume  subscribers  and 
emergency  restoration. 

The  Initial  AUTOOIN  II  network  will  consist  of  three 
PSNs  at  Ft.  Oe trick.  Tinker  AFB.  and  McClellan  AFB  with  a Network 
Control  Center  at  Headquarters  OCA.  The  acceptance  of  this  three 
node  network  establishes  the  FY  1980  IOC.  Subsequently,  a fourth  PSN 
will  be  added  at  Gentile  AFB.  The  growth  of  the  network  from  that 
point  will  depend  on  user  requirements  and  user  ability  to  provide 
the  software  and  hardware  Interfaces  needed  to  connect  to  the 
network.  It  Is  envisioned  that  the  network  service  will  grow 
Incrementally,  as  required,  to  meet  additional  requirements. 

There  are  two  basic  types  of  subscribers  to  the  AUTOOIN 
II:  network  hosts  and  terminals.  Hosts  are  computers  capable  of 
simultaneously  conducting  multiple  conversations  with  other  hosts  or 
terminals.  Host  computers.  In  general,  are  the  centers  of  major  AOP 
teleprocessing  systems  and  are  major  sources  of  network  traffic. 

Terminals  are  defined  as  either  bit  or  character 
oriented  devices  capable  of  conducting  a conversation  with  only  one 
destination  at  a time.  Terminals  may  operate  In  Interactive  (I /A), 
query/ response  (Q/R),  bulk,  or  narrative  message  applications. 
Terminal  devices  Include  computer  peripheral  controllers  and 
Intelligent  or  unintelligent  Input-output  devices.  The  PSN  will 


Interface  with  terminals  so  as  to  minimi ze  the  hardware  and  software 
Impacts  of  these  users.  Multiplexers  are  used  extensively  In  this 
network  to  minimize  the  cost  for  access  lines. 

In  a typical  AUTOOIN  II  network  data  flow,  the  traffic 
source  (computer,  terminal,  or  AUTOOIN  I ASC)  will  present  a data 
segment  to  the  source  PSN.  The  source  node  will  accept  traffic  one 
segment  or  character  at  a time  from  the  subscriber,  make  prescribed 
control,  security  and  coanunlty  of  Interest  checks,  format  the 
segment  Into  a packet  for  network  transmission  and  send  each  packet 
separately  Into  the  network  on  the  appropriate  trunk.  Intervening 
nodes  will  relay  the  data  packets.  The  destination  node  will  reform 
each  packet  into  subscriber  deliverable  traffic  In  the  form  of  a 
segment  (or  characters),  perform  outgoing  validation  checks,  deliver 
the  segment  or  characters  to  the  destination  terminal  and  acknowledge 


As  a major  subsystem  of  the  OCS.  AUTODIN  II  must  provide 
service  at  all  levels  of  security  from  unclassified  to  Top  Secret, 
Special  Intelligence.  To  meet  this  need,  the  AUTOOIN  II,  Phase  I 
communication  links  and  switch  facilities  will  be  secured  to  the 
highest  classification  level  transmitted,  and  will  be  capable  of 
being  compartmented  by  use  of  transmission  control  codes  (TCC)  and 
virtual  logical  channels.  Each  data  packet  will  be  verified  as  to 
the  authorized  security  level  and  communlty-of- Interest  of  both  the 
sender  and  receiver. 

Overseas.  Current  OCA  planning  for  AUTOOIN  II  provides 
for  achieving  service  on  a worldwide  basis  via  overseas  PSNs  as  early 
as  FY  1981  but  no  later  than  FT  1983.  Prior  to  fielding  PSNs. 
service  will  be  provided  solely  via  multiplexers.  Initial  PSNs  will 
be  located,  one  each  In  Europe  and  the  Pacific.  Additional  near-term 
overseas  service  may  be  provided  through  continued  use  of  local 
multiplexers  via  Intercontinental  trunk  (probably  satellite).  Final 
decisions  on  overseas  will  be  made  in  the  near-term. 

c.  Network  Elements.  The  major  architectural  elements  that 
exist  In  the  1983  Architecture  are  derived  from  the  AUTOOIN  I /I I 
networks.  These  elements  are  described  In  the  following 
subparagraphs. 

(1)  Packet  Switch  Node  (PSN).  The  PSN  Is  being  developed 
under  the  AUTOOIN  II,  Phase  I program  to  provide  backbone  switching 
for  both  the  AUTOOIN  II  and  AUTOOIN  I subsystems.  A simplified 
functional  block  diagram  of  the  PSN  Is  illustrated  in  Figure  3. 

As  Indicated  In  this  figure,  the  PSN  Includes  the  following  major 
subsystems: 
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LINE  CONTROL  MODULE 


SWITCH  CONTROL  MODULE 


• TRUNKS 

• HOSTS 

• BINARY 


TERMINAL  ACCESS  CONTROL  MODULE 


Figure  3.  PSN  Functional  Block  Diagram 
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Lint  Control  Modulo  (ICM).  The  l CM  provides  the 
communications  Intorfoco  end  protocol  functions  necessary  to 
Interface  to  trunks  as  well  as  host  computers  and  terminals 
terminated  at  the  PSN.  The  ICM  transfers  data  to  and  from  trunks  In 
the  form  of  packets;  to  and  from  host  computers  and  other  binary 
format  terminals  In  the  form  of  binary  segments,  and  to  and  from 
character  oriented  terminals  In  the  form  of  characters.  The  ICM 
exchanges  data  with  the  SCM  In  the  form  of  both  packets  and  segments 
as  needed. 


Switch  Control  Module  (SCM).  The  SCM  performs  the  basic 
packet  switching  function  within  the  PSN.  The  SCM  accepts  binary 
segments  or  packets  from  the  LCM,  processes  the  routing  and  control 
Information  contained  In  the  data,  and  returns  packets  or  segments  to 
the  LCM. 


Terminal  Access  Control  (TAC)  Module.  The  TAC  Is 
Included  In  the  PSN  to  permit  character  oriented  terminal  subscribers 
(both  AUTODIN  I and  II)  to  utilize  the  PSN.  The  TAC  Includes  a 
Terminal  Host  Protocol  (THP),  Transmission  Control  Protocol  (TCP) 
and  a Segment  Interface  Protocol  (SIP)  which  allow  conversion  between 
character  format  data  and  binary  segment  data  for  processing  by  the 
SCM.  The  TAC  capability  of  the  PSN  can  be  Implemented  outside  the 
PSN  Itself  at  remote  terminal  or  host  locations.  In  this  case  the 
remote  TAC  Interface  to  the  PSN  appears  to  be  a binary  segment 
format.  The  technical  features  and  performance  of  the  PSN  are 
described  In  the  System  Performance  Specification,  (Type  A)  for  the 
AUTOOIN  II.  Phase  I. 

(2)  AUTOOIN  Switching  Center  (ASC).  The  1983  architecture 
will  utilize  eleven  AUTOOIN  I ASCs.  The  4 ASCs  remaining  In  CONUS 
will  be  colocated  with  AUTOOIN  II  PSNs.  These  ASCs  will  terminate 
local  suoscrlbers  and,  by  means  of  special  TAC  "cut-through" 
arrangement  at  the  PSNs,  be  able  to  terminate  remote  subscribers  via 
the  PSN  backbone.  This  arrangement  Is  described  further  in  Section 
III  (paragraph  2b).  In  the  1983  architecture,  direct  trunking 
between  ASCs  will  also  be  used  to  provide  connectivity  among 

all  led/tactical  users,  overseas  ASCs  and  ASCs  colocated  with  PSNs 
both  In  CONUS  and  overseas. 

(3)  Automated  Message  Processing  Exchange  ( AMPE ) . The  1983 
architecture  will  Include  a large  number  of  MILDEP/Agency  operated 
AMPEs,  such  as  the  AMME.  LDMX,  NAVCOMPARS,  AF  AMPE,  and  Streamliner. 
These  AMPE  equipments  will  provide  local  message  processing  and 
communications  concentrator  functions  for  narrative/record  users. 


AMPEs  will  continue  throughout  the  near* term  to  be  homed  on 
designated  ASCs,  either  through  direct  ASC  termination  or  through  a 
Terminal  Access  Controller  (TAC)  Interface  at  a PSN. 

(4)  Near-Term  Inter-Service/ Agency  AMPE  (Near-Term  I-S/A 
ANPE).  Toward  the  end  of  the  near-term  some  degree  of  AMPE 
standardization  will  be  achieved  through  limited  Introduction  of  a 
Near-Term  I-S/A  AMPE  beginning  In  1982.  This  "standardized"  AMPE, 
while  not  capable  of  performing  the  complete  set  of  all  I-S/A  AMPE 
functions,  will  perform  an  agreed  upon  set  of  functions  In  an  agreed 
upon  standard  way  and  will  be  capable  of  satisfying  the  service 
requirements  for  some  percentage  of  subscribers  of  all  the  services 
and  agencies.  This  Near-Term  I-S/A  AMPE  Is  envisioned  to  be  based  on 
multiple  mini-processor  technology.  The  Near-Term  I-S/A  AMPEs  will 
be  homed  on  one  or  more  ASCs  throughout  the  near-term  as  the 
service  and  agency  AMPEs  are  now. 

(5)  Host  Computer.  Major  high  volume  computer  facilities  In 
user  communities  such  as  WUMCCS  and  SACOIM  will  Interface  directly  to 
PSNs  In  the  Near-Term  Architecture.  These  are  computers  capable  of 
simultaneously  conducting  multiple  conversations  with  multiple 
destinations.  The  Interface  will  use  binary  segment  leaders 
principally  In  Mode  VI.  These  hosts  are  centers  of  major  ADP 
activity  and  are  major  sources  of  network  traffic.  (Note:  small 
volume  AOP  systems  will  probably  be  categorized  as  terminals  and  be 
connected  to  ASCs  or  PSNs  In  a standard  mode;  or  connected  to  AMPEs 
or  Near-Term  I-S/A  AMPEs  In  either  a standard  or  subscriber  specified 
mode) . 

(6)  Terminal.  A wide  variety  of  terminals  will  exist  In  the 
1983  architecture.  Typical  characteristics  of  the  AUTOOIN  I type  and 
AUTODIN  II  type  terminals  anticipated  In  this  period  are  shown  In 
Table  I.  Terminals  are  defined  as  character  oriented  devices 
capable  of  conducting  a single  coversatlon  and  range  from 
teletypewriters  up  through  small  computers. 

(7)  Multiplexer.  Multiplexers  will  be  used  In  the  1983 
architecture  wherever  practical  In  oraer  to  effect  transmission 
efficiency  and/or  cost  reduction. 

d.  1983  Architecture  Configuration.  The  anticipated  1983 
architecture  Is  Illustrated  In  Figure  4.  This  schematic  diagram 
Illustrates  the  generic  configuration  of  network  elements  both  In 
CONUS  and  overseas.  This  basic  configuration  Is  described  In  the 
following  subsections. 


TABLE  I.  1983  ARCHITECTURE  TERMINAL  CHARACTERISTICS 


Types  - teletypewriter,  card,  magnetic  tape,  facsimile, 


multimedia,  computer  Interface,  AMPE 


Codes  - ASCII,  ITAc2,  Fleldata 


Speeds  - 45  thru  4800  bps 


Formats  - JANAP  128,  ACP  127,  DOI  100/103 


Types  - teletypewriter,  card,  magnetic  tape,  facsimile, 
CRT,  sensors,  multimedia,  host  computers 


• I,  IB,  IIA,  VI  link  protocols  end  end-to-end 


host  protocols 


Codes  - ASCII,  others  (transparent  to  network) 


- 110-56k  bps 


Formats  - binary  and  character  segment  formats,  message  formats 
transparent  to  network 


(1)  CONUS.  The  anticipated  backbone  In  CONUS  will  Include 
up  to  eight  PSNs  with  four  colocated  ASCs.  The  trunk  network 
connecting  these  PSNs  will  be  sized  both  for  survivability  and  speed 
of  service  considerations. 

The  access  region  In  CONUS  will  consist  of  MIlDEP/Agency 
unique  AMPE  and  Mean-Ten*  I-S/A  AM PE  equipments  and  an  assortment  of 
AUTOOIN  1 and  AUTOOIN  II  type  terminals  connected  via  local 
communications  facilities  to  either  AMPE.  Near-Term  I-S/A  AMPEs. 

ASCs.  or  PSNs.  It  Is  not  anticipated  that  the  current  AUTOOIN  I 
subscriber  network  within  CONUS  will  change  significantly  during  the 
near-term.  The  major  change  In  the  access  area  during  the  near-term 
therefore,  will  be  represented  by  the  Introduction  of  a significant 
number  of  AUTOOIN  II  host  computer  and  subscriber  terminals. 

(2)  Overseas.  The  overseas  backbone  In  the  1983 
Architecture  will  depend  heavily  upon  existing  ASC  assets. 

Although  Implementation  of  overseas  PSNs  Is  planned  for  the 
near-term,  significant  replacement  of  ASC  operation  overseas  will 
probably  not  be  accomplished  by  the  end  of  the  near-term  time 
period.  A significant  feature  of  the  overseas  backbone  will  be  the 
direct  Interface  between  all  led/ tactical  users  and  ASCs  (at  least 
two  NATO  Interface  trunks  are  also  anticipated  for  CONUS).  The 
access  area  overseas  Is  expected  to  be  dominated  by  the  existing 
AUTOOIN  I terminals  (Including  AMPEs).  The  Introduction  of 
AUTOOIN  II  terminal  and  host  computer  Interfaces  overseas  Is 
dependent  upon  the  Introduction  of  packet  service  overseas.  It  Is 
anticipated  that  by  1983  this  service  will  be  readily  available  In 
Europe  and  to  a lesser  degree  In  the  Pacific. 

As  evidenced  by  the  schematic  diagram  of  Figure  4 and 
the  preceding  descriptions,  although  full  Integration  of  the  AUTOOIN 
System  will  not  be  possible  In  the  near-term,  significant  sharing  of 
backbone  assets  will  have  been  accomplished.  In  addition,  the 
consol Idatlon/closure  of  ASC  sites  both  In  CONUS  and  overseas  should 
significantly  reduce  cost  of  operation  and  maintenance  (0AM) 
associated  with  the  total  AUTOOIN  System.  However,  the  1983 
architectural  configuration  does  represent  significant  potential 
problems  In  the  area  of  survivability  through  the  Introduction  of 
choke  points  In  the  total  network  operation.  It  must  be  recognized 
therefore,  that  the  1983  architecture  Is  not  an  end  In  Itself,  but 
rather  a conceptual  milestone  In  the  continued  evolution  of  the 
Integrated  AUTOOIN  System. 

e.  Connectivity  In  the  1983  Architecture.  The  major  Interfaces 
that  will  exist  In  the  1983  architecture  are  Illustrated  In  Figure 
S.  The  basic  link  protocol  and  Interface  characteristics  of  the 
1983  architecture  are  described  In  Table  It. 


Figure  5.  Near-Term  Connectivity 


TABLE  II.  1983  ARCHITECTURE  CONNECTIVITY 


CONNECTION 

U.WK  PROT^ 

c 

PSN-PSN 

Blnory  Pockot 

PSN-AOP  Host 

Mod#  VI,  Blnory  Sogmont  Loodor  (BSL) 

c 

PSM-ASC 

Mod#  VI  BSL 

PSN-Tomlnol  (Typo  II) 

Modo  IB,  II  or  VI  Choroctor  vlo 
Tornlnol  Acctss  Controllor  (TAC) 

l» 

PSN-AMPE/Toml m 1 (Typo  I) 

Mod#  I,  Choroctor  (vlo  TAC) 

ASC-ASC 

Nodo  I,  DIN  I (SwItch-to-SwItch) 

c 

ASC/ATPE-Tomlnol  (Typo  I) 

Modo  I,  II,  V,  OIN  I (Tornlnol) 

ASC-NICS  (TARE) 

Nodo  I,  OIN  I (Tornlnol) 

o 

ASC-TYC-39 

Nodo  I,  OIN  I (Tornlnol) 
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f.  Tactical  Interfaces.  The  two  principal  tactical  Interfaces 
for  the  Integrate*  AUTOOIN  System  are  anticipated  to  be  operational 
by  1963.  These  Interfaces  are  the  AN/TYC-39  Automatic  Message  Relay 
developed  under  the  TRI-TAC  program  and  the  MATO  Improved 
Communications  System  Tactical  Automatic  Relay  Equipment  (NICS/TARE). 
Interface  to  both  of  these  systems  In  the  1963  Architecture  will  be 
accomplished  via  direct  connection  to  designated  ASCs.  (It  should  be 
noted  that  while  ASCs  are  the  preferred  connection  point,  any  access 
node  with  a compatible  Interface  could  be  used.)  Overseas  both 

the  AN/TYC*39  and  the  NICS/TARE  Interface  will  be  accomplished 
through  designated  ASCs.  In  CONUS  one  or  more  of  the  colocated 
ASC/PSN  sites  will  be  designated  as  the  NATO  Interface.  It  Is 
anticipated  that  both  the  NICS/TARE  system  and  the  AN/TYC-39  relay 
will  employ  an  AUTOOIN  I,  Mode  I,  terminal  Interface  and  that  this 
protocol  will  provide  the  basic  access  mechanism.  Although  these 
Interfaces  are  not  considered  optimal  for  the  eventual  Integrated 
system  operation.  It  Is  not  considered  feasible  to  accomplish 
significant  protocol /Interface  modifications  within  the  time 
constraints  of  the  near-term.  Therefore.  Implementation  of  new 
access  arrangements  for  tactical /all led  users  will  be  accomplished  In 
the  mid-term. 

g.  Security.  The  1963  architecture  will  depend  upon 

1 Ink-by-link  encryption  similar  to  that  employed  In  the  current 
AUTOOIN  I System.  The  cryptographic  equipments  used  for  this  purpose 
will  Include  the  existing  KG-13  and  Kfr-34  as  well  as  newer  devices 
such  as  the  KG-84.  key  variable  distribution  for  these  equipments 
will  continue  to  be  off-line  and  essentially  a manual  operation. 

In  addition,  the  AUTOOIN  II  protocols  will  employ  security 
level  and  transmission  control  codes  In  message  headers  to  enhance 
the  protection  and  separation  provided  for  user  Information  In  the 
PSNs. 


The  current  consolidation  of  special  Intelligence  (SI)  and 
general  service  (GENSER)  traffic  within  the  AUTOOIN  I ASCs  permits  a 
single  terminal  (e.g.,  AMPE)  to  transmit  and  receive  SI  and  GENSER 
traffic.  However,  the  terminal  must  operate  In  an  SI  accredited 
environment  In  system  high  mode  with  Si-cleared  operators.  By  1983 
efforts  will  be  complete  to  consolidate  SI  and  GENSER  traffic  Into 
Near-Term  I-S/A  AMPEs  which  can  be  certified  to  joint  DIA/NSA 
criteria. 


h.  Operation.  Procedures  end  protocols  utilized  In  the  1983 
architecture  for  narrative/record  message  operation  will  he  basically 
unchanged  from  the  current  AUT001N  1 system.  As  discussed  earlier, 
AHPE  and  terminal  equipments  will  have  a designated  home  ASC.  This 
ASC  will  provide  the  same  terminal  support  and  message  processing 
functions  as  In  the  current  system.  Precedence  and  preemption 
processing  will  remain  unchanged.  Current  message  formats  (JANAP 
128,  ACP  127,  001  103)  will  be  employed  as  well  as  the  00-173  joint 
message  form  and  a joint  plain  language  address  directory.  The  three 
principal  modes  of  operation  Identified  as  AUT001N  1 standaros  (Mode 
I,  Mode  II,  and  Mode  V)  will  remain  In  common  use.  Procedures  and 
protocols  associated  with  these  modes  of  operation  will  be 
essentially  unchanged  for  narrative/record  users. 

Procedures  and  protocols  for  computer  oriented  data  users  of 
the  1983  AUTOOIN  II  network  will  be  developed  under  the  AUTOOIN  II 
program.  At  least  four  major  link  protocols  (I,  IB,  IIA,  and  VI)  as 
well  as  an  end-to-end  host  protocol  are  defined  for  the  AUTOOIN  II 
system  (Reference  b).  AUTOOIN  II  binary  and  character  formats  as 
well  as  special  message  formats  for  data  users  will  be  well  defined 
by  the  1983  time  period.  In  general.  It  Is  anticipated  that  AUTOOIN 
II  subsystem  Implementation  will  be  esentlally  complete  within  the 
1978-1983  time  frame.  Operating  procedures  and  protocols  will  be 
well  established  and  provide  a sound  basis  for  expansion  of  service 
both  In  CONUS  and  overseas  throughout  the  mid-term. 

1.  Summary.  As  evidenced  by  the  preceding  description,  the 
architecture  of  1983  will  provide  an  AUTOOIN  System  that  Is,  In 
general,  responsive  to  the  needs  of  both  narrative/record  and  data 
users.  In  defining  the  next  major  evolutionary  step  toward  the 
Integrated  AUTOOIN  System  to  be  taken  In  the  mid-term,  the  following 
characteristics  of  the  1983  architecture  should  be  considered: 

o The  architecture  of  1983  represents  a consolidation  of  two 
essentially  Independent  networks  with  significant  sharing  of 
backbone  assets  and  two  co-existing  user  communities  with 
distinct  operating  procedures,  access  arrangements  and 
equipment  Inventories. 

o The  architecture  of  1983  represents  an  Increase  In  the 
standardization  of  AHPE  and  terminal  operation/configuration 
through  Introduction  of  Near-Term  Inter-Service/Agency  AMPEs. 

o The  AUTOOIN  system  of  1983  will  provide  significantly  Improved 
performance  and  service  for  data  users  through  the 
capabilities  of  the  AUTOOIN  II  subsystem. 
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The  architecture  of  1983  represents  little  or  no  reel 
Improvement  In  system  survivability,  security,  or  operational 
flexibility  over  the  current  AUTOOIN  I system  for 
narrative/record  users. 

o The  AUTOOIN  system  of  1983  represents  significant  Improvement 
In  cost  effectiveness  as  a result  of  the  closure  of  at  least 
four  CONUS  ASCs  and  colocation  of  ASC  and  PSN  sites. 

As  a result  of  these  and  other  architectural  considerations.  It  Is 
clear  that  the  architecture  of  1963  does  not  represent  an  acceptable 
conclusion  to  the  Integration  process.  Therefore,  the  need  for 
continued  evolution  to  a Mid-Term  Integrated  AUTOOIN  System 
Architecture  Is  clear.  In  the  next  section,  the  process  of  defining 
alternative  archl tectures  for  the  mid-term  Is  Initiated  with  the 
discussion  of  the  constraints  on  the  mid-term  architecture. 

( 

2.  CONSTRAINTS  ON  THE  MID-TERM  IAS  ARCHITECTURE 

The  mid-term  architecture  for  the  Integrated  AUTOOIN  System  (IAS) 
will  provide  an  archl tectural  framework  for  the  evolutionary 
development  of  the  Automatic  Digital  Network  (AUTOOIN)  during  the 
period  1964-1968.  The  IAS  architecture  Is  not  Intended  to  represent 
a new  system  that  must  be  developed  and  superimposed  on  existing 
common  user  DoO  systems  In  a competitive  or  duplicative  manner.  It 
Is  rather  Intended  as  a vehicle  to  guide  the  evolution  of  DoD  data 
telecommunications  towards  a more  secure,  survlvable,  efficient,  and 
cost  effective  means  of  satisfying  both  narrative/record  and  data 
communications  requirements  throughout  the  1980-1990  time  frame. 
Consistent  with  this  philosophy,  the  Integrated  AUTOOIN  System 
architecture  for  the  mid-term  Is  necessarily  constrained  In  Its  scope 
and  direction.  Coincidentally,  the  process  of  defining  the  Mid-Term 
Architecture  for  the  IAS  Is  constrained  to  consider  only  those 
archl tectural  alternatives  which  are  technically  and  economically 
feasible  within  the  mid-term  time  frame,  consistent  with  the 
objectives  of  the  Integrated  AUTOOIN  System  Architecture,  and 
finally,  consistent  with  the  evolutionary  philosophy  of  the 
Integrated  AUTOOIN  System.  The  following  subsections  present  some  of 
the  principal  constraints  on  the  mid-term  architecture  and  identify 
the  Implications  of  these  constraints  on  the  architecture  definition 
process. 

a.  Current  AUTOOIN  I Inventory  Assets.  Currently  Installed 
AMPEs  and  terminal  equipments  of  the  AUTOOIN  I network  as  well  as 
those  Installed  during  the  period  1978-1983  will  have  a significant 
useful  life  extending  Into  (and  In  some  cases  through)  the  mid-term 
time  frame.  The  evolutionary  Implementation  of  the  IAS  precludes  the 


wholesale  replacement  of  these  equipments  during  the  mid-term. 
Therefore,  the  Mid-Term  Architecture  must  provide  for  support  of 
AUTOOIN  I.  Mode  I.  character  format  terminals  and  AMPEs  throughout 
the  mid-term  time  frame.  The  Implication  of  this  constraint  is  most 
significant  upon  the  functional  definition  of  the  nodal  elements 
which  must  interface  these  current  Inventory  AUTOOIN  I AMPEs  and 
terminals.  In  addition  to  providing  the  obvious  link  protocols,  the 
nodal  elements  required  to  support  surviving  AUTOOIN  I subscriber 
equipments  must  also  provide  all  terminal  support  functions  formerly 
provided  by  the  ASCs.  This  has  the  effect  of  defining  the  minimum 
functional  capability  of  these  nodal  elements.  If  and  when  AUTOOIN  I 
servlce(s)  (e.g.,  guaranteed  sequential  bulk  delivery)  can  be 
accomodated  by  an  AUTOOIN  II  service,  then  and  only  then  will  the 
AUTOOIN  I service  be  phased  out. 

b.  Current  AUTOOIN  II  Development  Status.  The  currently  planned 
AUTOOIN  II  will  provide  4 PSNs  with  options  for  up  to  4 additional 
PSNs.  This  network  of  up  to  8 PSNs  will  provide  the  basic  backbone 
for  the  Mid-Term  Integrated  AUTOOIN  System.  8ased  on  the  early  IOC 
and  the  advanced  degree  of  definition  of  network  operating  modes, 
protocols,  and  Interfaces,  It  Is  not  considered  feasible  to 
significantly  change  the  design  of  these  elements.  Therefore,  the 
Mid-Term  IAS  Architecture  will  be  based  upon  utilization  of  these 
PSNs  with  minimum  If  any  modifications. 

c.  Inter-Service/Agency  AMPE  Program  Status.  In  a recent 
memoranda,  the  ASO  (C3I)  reiterated  the  objectives  of  the  IAS 
Architecture  program  and  established  the  need  for  an 
Inter-Service/Agency  AMPE  (I-S/A  AMPE)  Program  as  an  Initial  step 
toward  successful  Implementation  of  an  Integrated  AUTOOIN  System 
(Reference  c).  The  proposed  program  envisions  a Near-Term  I-S/A  AMPE 
that  would  be  available  as  soon  as  1982  and  a full  capabl laity  I-S/A 
AMPE  family  fielded  beginning  In  1984/1985.  This  NS/A  AMPE  program 
provides  a viable  mechanism  for  providing  many  of  the  functional 
capabilities  required  In  the  Mid-Term  IAS  Architecture.  Therefore. 

t ,e  Mid-Term  IAS  Architecture  definition  Is  based  upon  the  assumption 
of  the  availability  of  such  a full  capability  I-S/A  AMPE  family  In 
time  for  mid-term  use. 

d.  Available  Technology.  Based  on  current  OoO  experience  with 
new  technology  Introduction,  and  the  development  cycle  required  for 
communication  system  Implementation,  new  network  elements  to  be 
Introduced  during  the  mid-term  must  be  based  upon  currently  available 
technology.  This  precludes  the  Introduction  during  the  mid-term  of 
two  of  the  principal  long-term  architectural  objectives  Identified  by 


OCA  In  previous  studios.  1.#..  Integrated  voice  and  data  and  the  use 
of  multiple  access  satellite  broadcast  capability.  However,  the 
long-term  promise  of  these  technologies,  and  the  probability  of  their 
successful  development  cannot  be  Ignored.  Therefore,  these  advanced 
technologies  are  assumed  to  be  available  for  Far-Ten  IAS 
Implementation  (Post  1968).  In  addition,  the  mid-term  architecture 
definition  will  consider  the  Impact  of  this  eventual  far- term 
evolution  on  the  Mid-Term  Architecture  Itself.  This  will  Insure  that 
near-term  architectural  decisions  do  not  preclude  successful 
continued  evolution  of  the  IAS. 

3.  APPROACH  TO  MID-TERM  ARCHITECTURE  DEFINITION 

As  noted  earlier  the  Integrated  AUTOOIN  System  Architecture 
definition  process  Is  being  conducted  in  three  parts  corresponding  to 
the  three  time  periods  of  the  IAS  Implementation: 

o Near-Term  (1978-1983) 

o Mid-Term  (1984-1988) 

o Far-Term  (Post  1988) 

The  architecture  definition  process  performed  In  support  of  the 
near-term  planning  was  necessarily  concentrated  on  Identification  and 
analysis  of  Implementation  alternatives.  This  analysis  was  limited 
to  consideration  of  network  elements  available  from  the  existing 
AUTOOIN  I Inventory  and  elements  already  under  development  In  the 
AUTOOIN  II  program.  Similarly,  configuration  and  connectivity 
alternatives  were  limited  by  the  capability  Inherent  In  these 
elements. 

The  architecture  definition  process  In  support  of  the  mid-term  Is 
considerably  broader  In  scope  than  that  performed  for  the  near-term 
from  two  standpoints:  First,  because  the  start  of  the  aid-term 
(1984)  Is  sufficiently  advanced  to  permit  development  of  new  network 
elements,  some  degree  of  functional  definition  and  reallocation  Is 
possible.  Secondly,  as  a result  of  the  potential  functional 
redeflnltlon/reallocatlon  at  the  nodal  element  level,  new 
configuration  and  connection  alternatives  at  the  overall  systems 
architecture  level  are  possible. 

The  approach  to  architecture  definition  employed  for  the  Mid-Term 
IAS  Architecture  reflects  these  differences  from  the  near-term.  In 
the  near-term,  architecture  definition  was  Issue  oriented  and 


addressed  specific  options  available  to  the  system  Implemented  The 
Mid-Ten*  Architecture  definition  process  on  the  other  hand.  Is  aimed 
toward  definition  of  a top  down  overall  architectural  description. 

The  approach  to  defining  the  Mid-Term  IAS  Architecture  was  based 
on  the  following  three  analysis  efforts: 

o Definition  of  mid-term  requirements  and  operating  environment 

o Generation  of  candidate  architectures  and  selection  of 
alternative  architectures  from  among  viable  candidates. 

o Evaluation  of  alternatives  and  selection  of  a preferred 
architecture 

The  following  sections  present  the  results  of  these  architecture 
definition  analyses. 

4.  MID-TERM  REQUIREMENTS  AND  OPERATING  ENVIRONMENT 

This  section  presents  the  projected  user  requirements  for  the 
mid-term  Integrated  AUTOOIN  System  and  defines  the  anticipated 
environment  In  which  the  IAS  must  operate. 

a.  Sources.  The  projected  IAS  mid-term  user  requirements  were 
derived  from  the  following  source  douements: 

o Preliminary  IAS  Requirements  Definition,  DCEC,  October  1977 

o Switch  Networks  Automatic  Profile  System,  Network  Profile 
(Sample  Days) 

o AUTODIN  II,  Phase  I Performance  Specification,  XS,  November 
1975 

o IAS  ARCHITECTURE  Report.  December  1977 

o AUTOOIN  II,  Phase  I Business  Plan,  OCA,  November  1976 

o AUTOOIN  II  Oata  Base.  OCEC.  December  1977 

Information  to  Support  AUTODIN  Planning  Studies,  OCA,  August 
1977 
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b.  Projected  IAS  Traffic  Input.  The  projected  busy  hour  average 
traffic  Input  for  the  Integrated  AUTOOIN  System  In  the  period 
1978-1988  Is  Illustrated  In  Figure  6.  This  traffic  Input  Is  based 
on  projections  of  the  AUTOOIN  I and  AUTODIN  II  current  and  projected 
traffic  patterns. 

(1)  AUTODIN  I Traffic.  The  AUTOOIN  II  Type  A Specification 
(Reference  b)  estimates  the  total  AUTOOIN  I traffic  Input  to  AUTOOIN 
II  PSNs  at  4.9  X 10(8)  bits  per  busy  hour  In  1980.  This  represents 
AUTOOIN  I trunk  traffic  only  since  Intra-ASC  traffic  will  not  be 
presented  to  the  PSNs.  Based  on  a survey  of  sample  days  from  the 
Switch  Networks  Automatic  Profile  System,  The  AUTOOIN  I local  ASC 
traffic  volume  averages  approximately  1/3  of  the  ASC  trunk  traffic 
volume.  Therefore,  the  total  Input  busy  hour  traffic  from  AUTOOIN  I 
type  subscribers  In  1980  Is  estimated  to  be  4.9  X 10(8)  (trunk)  plus 
1.6  X 10(8)  (local)  for  a total  of  6.5  X 10(8)  bits. 
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The  AUTOOIN  I traffic  growth  up  to  1980  was  found  to  be 
11  percent  per  year  based  on  recent  AUTOOIN  I traffic  volumes 
(Reference  d).  Since  some  computer  oriented  users  of  AUTOOIN  I are 
expected  to  convert  their  bulk  data  traffic  to  AUTOOIN  II,  a decrease 
In  the  rate  of  growth  In  AUTOOIN  I traffic  Is  expected  after  AUTOOIN 
II  Is  Implemented.  AUTODIN  I type  traffic  growth,  therefore.  Is 
projected  at  6 percent  per  year  after  1980.  These  projections  result 
In  a total  AUTOOIN  I busy  hour  Input  traffic  volume  of  1.2  X 10(9) 
bits  or  an  average  of  334  kbps  In  1988. 

(2)  AUTODIN  II  Traffic.  The  Preliminary  IAS  Requirements 
Definition  of  October  1977  (Reference  o)  estimates  the  total  AUTOOIN 
II  busy  hour  traffic  Input  (exclusive  of  AUTOOIN  I traffic)  at  4.74  X 
10(9)  bits  In  1982.  A rapid  growth  in  traffic  volume  to  this  level 
can  be  expected  as  subscribers  are  phased  into  the  system  between 
mld-1980  and  mld-1982.  After  1982,  the  growth  will  probably  level 
off  to  that  of  a mature  system.  The  Increase  In  the  volume  of  this 
type  of  traffic,  was,  therefore,  estimated  at  11  percent  per  year  in 
accordance  with  the  recent  growth  pattern  of  AUTOOIN  I traffic. 

The  AUTOOIN  II,  Phase  I System  Performance  Specification 
(Type  A)  (Reference  b)  provides  estimates  for  the  relative  proportions 
of  transactions  and  averaqe  transaction  length  by  traffic  type.  It 
also  estimates  the  ratio  of  computer  to  terminal  Input  traffic. 

These  estimates  were  used  to  derive  traffic  volumes  by  transaction 
type  and  subscriber  type.  The  results  are  shown  In  Table  III. 
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TABLE  III.  AVERA6E  BUSY  HOUR  TRAFFIC  INPUT  FROM  AUTODIN  II-TYPE 

SUBSCRIBERS  (1988) 


iEitfiiL  Twt 

input 

Hat, mil 

Rata 

TaSutars  (kbos) 

Narratlva/Racord 

99 

22 

Bulk 

207 

2089 

Intaractlva  and 

Qutry/Rasponsa 

S 

36 

Total 

311  kbps 

21 S8  kbps 

c.  Projected  Terminal  Population. 

(1)  AUTODIN  I Terminals.  The  number  of  access  lines 
connected  to  AUTOOIN  I ASCs  has  remained  relatively  constant  at 
approximately  900  In  CONUS  and  500  overseas  for  the  period  1970  to 
1978.  Adjusting  for  dual  connection  of  terminals  and  the  estimated 
AMPE  population,  the  number  of  AUTOOIN  I terminals  connected  to  the 
network  Is  estimated  to  be  approximately  800  In  CONUS  and  400 
overseas.  In  the  near-term  the  trend  toward  relocation  of  terminals 
behind  AMPEs  Is  expected  to  offset  any  Increases  In  user  requirements 
for  additional  terminals.  Therefore,  the  projected  IAS  AUTOOIN  I 
subscriber  population  throughout  the  mid-term  Is  estimated  at  800  In 
CONUS  and  400  overseas.  Additionally,  the  IAS  will  ultimately  serve 
today's  AMPE  remotes. 

(2)  AUTOOIN  II  Terminals.  The  number  of  terminals 
(exclusive  of  AUTOOIN  I)  and  host  computers  connected  to  AUTOOIN  II 
PSNs  by  1982  Is  estimated  to  be  approximately  1900  and  ISO 
respectively, based  on  current  validated  DoO  user  requirements 
(Reference  e).  The  rate  of  growth  In  AUTOOIN  II  terminals  and 
computers  connected  to  the  network  beyond  1982  Is  dependent  on  many 
factors  Including:  user  data  processing  requirements;  growth  of 
distributed  processing  use  In  OoD;  network  service  offerings;  and 
DoD/MILDEP/Agency  policy.  For  the  purpose  of  this  analysis.  It  Is 
assumed  that  all  validated  OoO  user  requirements  for  AUTOOIN  II 
service  Identified  by  1962,  will  be  satisfied  by  the  Initial 
operational  system.  Therefore,  It  Is  unlikely  that  a significant 
number  of  new  requirements  will  be  Identified  and  validated  In  the 
1983-1988  time  period  Immediately  following  the  AUTOOIN  II 
Implementation.  For  these  reasons,  a modest  growth  rate  Is 
anticipated  for  this  period.  The  projected  1988  AUTOOIN  II  total 
terminal /host  population  based  on  this  growth  rate  Is  approximately 
1800  terminals  and  host  computers. 

d.  Projected  AMPE  and  I-S/A  AMPE  Population.  Ourlng  the  mid-term 
time  period,  most  of  the  current  AMPE  equipments  Installed  between 
1970  and  1980,  will  reach  the  end  of  their  useful  life.  The  new 

In ter- Service/Agency  AMPE  will  be  used  to  replace  these  AMPEs,  as 
well  as  to  meet  new  AMPE  requirements.  However,  since  the  I-S/A  AMPE 
Is  capable  of  supporting  all  service/agency  users,  at  all  levels  of 
security,  a number  of  current  AMPE  sites  can  be  consolidated  through 
joint  use  of  a single  I-S/A  AMPE.  In  order  to  project  the  total  AMPE 
and  I-S/A  AMPE  population  In  the  mid-term  IAS,  an  analysis  of  current 
and  planned  AMPE  sites  was  performed  (See  Appendix  A).  Results  of 
this  analysis  are  summarized  In  Figure  7.  As  Illustrated  In  this 
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figure,  total  population  of  AMPE/I-S/A  AMPE  sites  will  peak  at 
approximately  112  In  1964  and  eventually  settle  to  less  than  110  In 
1968.  It  should  be  noted  that  this  represents  approximately  30X  less 
than  the  number  of  AMPE  sites  required  If  the  current  AMPE  programs 
were  extended  at  even  a modest  rate  of  growth.  In  addition,  the 
(j  actual  number  of  AMPE  installations  In  the  mid-term  wllloe  based 

upon  many  factors  not  considered  In  this  analysis,  such  as  specific 
service/agency  operational  and  survivability  requirements.  The 
results  of  this  analysis  are.  therefore.  Intended  only  to  support  the 
architecture  definition  process  and  are  not  proposed  as  a OCA 
replacement/consol Idatl on  pol Icy. 

e.  Services.  The  mid-term  IAS  will  provide  a full  range  of  data 
services  to  most  subscribers.  These  services  will  Include  the  basic 
narrative/record  services  currently  provided  by  the  AUTOOIN  I system, 
the  new  computer  oriented  services  defined  for  the  AUTOOIN  II  system, 
and  several  new  data  services,  patterned  after  the  ARPANET 
capabilities  that  have  demonstrated  a high  degree  of  user  acceptance. 
As  part  of  the  IAS  architecture  definition  process  a number  of  basic 
services  were  Identified  and  defined  sufficiently  to  be  considered 
valid  requirements.  It  Is  anticipated  that  additional  services  will 
be  defined  throughout  the  near-term  based  on  user  experience  with  the 
AUTOOIN  II  system  and  evolving  data  needs.  The  basic  IAS  mid* term 
service  requirements  can  be  organized  Into  seven  categories  described 
' In  the  following  subsections. 

(1)  Narrative/Record  Message  Transfer.  This  service 
Includes  the  secure  user-to-user  transfer  of  message  traffic  provided 
by  the  current  AUTOOIN  I System.  Using  this  service  a user  In  the 
system  (properly  equipped  and  within  appropriate  Interest  community) 
o may  transmit  narrative/record  traffic  to  one  or  more  other  users. 

The  major  service  features  provided  by  the  network  are  message 
accountability  and  retrieval,  multiple/collective  address  routing, 
and  code  and  format  conversions.  This  service  will  be  available  to 
all  IAS  subscribers  In  some  form. 

C (2)  Narrative/Record  Message  File  Retrieval.  This  service 

provides  storage  of  message  traffic  on-line  for  retrieval  upon 
request  from  users.  Narrative/record  messages  passing  through  the 
network  are  automatically  stored  for  a prescribed  period  of  time. 
Other  data  such  as  standard  forms  may  be  also  stored  by  a user  for 
later  recall.  The  nodal  elements  which  contain  the  message  files 
O perform  the  processing  to  store  messages,  control  access  to  the  files 

and  remove  messages  from  the  file  at  user  direction  or  time 
expiration.  The  service  Is  presently  provided  In  various  forms  by 
some  AMPEs  In  the  current  AUTOOIN  1 system,  and  will  be  provided  to 
all  narrative/record  subscribers  of  the  IAS. 
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m aup  transaction  Transfer.  This  service  provides  both 
secure  and  nonsocuro  Interactive.  query/response  and  bulk  data 
transfar  as  presently  daflntd  for  tht  AUTOOIN  II  network.  No  message 
processing  functions  or  accountability  art  provided  by  tht  network. 
Traffic  enured  Into  the  network  contains  segment  leader  Information 
and  Is  routed  through  the  network  on  a packet  basis.  Only  packet  or 
segment  In- transit  storage  Is  provided.  This  service  will  be 
available  to  computer  oriented  IAS  subscribers. 

(4)  Privacy  Service.  This  service  Is  equivalent  to  the 
present  AUTOOIN  I Limited  Privacy  Service.  The  traffic  Is  handled  as 
normal  narrative/record  traffic  except  that  no  permanent  history  or 
retrieval  storage  Is  retained  In  the  system.  The  service  will  be 
available  to  narrative/record  subscribers.  (This  type  of  privacy  Is 
Inherent  for  ADP  transactions  since  no  record  of  that  traffic  Is 
retained  In  the  system.) 


(5)  Informal  Message  Exchange.  This  service  allows  for  the 
exchange  of  Informal  or  unofficial  Information  among  users.  It  Is 
similar  to  narrative/record  message  transfer  except  limited  network 
functions  are  provided.  An  abbreviated,  simplified  format  Is  used 
and,  therefore,  no  format  conversion  Is  provided,  l.e.,  only 
In-transit  storage  Is  provided.  The  service  is  available  to  all  IAS 
subscribers. 

(6)  Mailbox  Service.  Mailbox  service  allows  a user  to  send 
messages  to  a storage  location  In  the  network  for  subsequent 
retrieval  by  the  addressee.  Mailbox  service  Is  an  augmentation  to 
the  Informal  message  exchange  service. 

(7)  Oata  Teleconferencing.  This  service  allows  a conference 
to  be  conducted  among  network  subscribers  using  teletypewriters, 

CRTs,  or  similar  terminal  devices.  Conferencing  may  be  simultaneous 
(conference  members  exchange  transactions  on  a real-time  basis)  or 
delayed  (members  enter  and  retrieve  transactions  at  their  own 
convenience).  A transaction  may  be  addressed  to  the  conference  or  to 
any  member  of  the  conference.  A network  element  will  control  the 
conference,  store  conference  transactions  and  respond  to  requests  for 
conference  data  or  status  Information  from  the  members.  The  data 
teleconference  service  is  an  augmentation  of  the  Informal  message 
exchange  service  and  will  be  available  to  most  subscribers. 

^ /unct1on**  Important  aspect  of  the  mid-term  architecture 
definition  process  Is  the  Identification  of  network  functions  and  the 
allocation  of  these  functions  to  appropriate  network  el  aments.  As  a 
first  step  In  this  process,  an  analysis  was  performed  In  order  to 


Identify  existing  AUTOOIN  I,  proposed  AUTODIN  II,  and  new  functions 
necessary  to  support  future  IAS  network  services.  As  a result  of 
this  analysis  81  specific  functions  were  identified.  In  order  to 
simplify  future  discussions  of  the  functional  allocation  process,  it 
Is  convenient  to  categorize  these  functions  as  follows: 

o ASC  Terminal  Support  Functions  - functions  performed  by  ASCs 
to  assist  terminal -to- terminal  message  exchange,  e.g.,  format 
validation,  format/code  conversion,  accountability,  and 
message  storage  and  retrieval 

o ASC  Network  Functions  - functions  performed  by  the  ASCs  to 
accomplish  routing  of  messages  through  the  system,  e.g., 
multiple/collective  address  routing,  message  control  block 
(e.g.,  looping  control),  CARP  routing,  and  precedence 
processing 

o PSN  Network  Functions  - functions  performed  by  PSNs  to 
accomplish  routing  and  control  of  data  flow  through  the 
network 

o New  Network  Functions  *•  functions  necessary  to  provide  new  IAS 
services,  e.g.,  teleconferencing  and  mailbox 

o Subscriber  Termination  - provision  of  network -access  to 
subscribers.  Includes  physical,  electrical  and  link  protocol 
Interface.  Does  not  Include  provision  of  network  services 

o Tactical /All led  Interface/Gateway  - Interface  Includes 
physical,  electrical  and  link  protocol(s);  gateway  Includes 
routing  functions  and  support  functions  (e.g.,  protocol /format 
conversion). 

As  part  of  the  detailed  technical  analysis  performed  In  support  of 
the  IAS  architecture  definition,  the  81  IAS  functions  were  mapped 
Into  the  general  service  categories  Identified  In  the  preceding 
subsection.  In  addition,  for  each  alternative  architecture,  these 
functions  were  allocated  to  the  network  service  elements  associated 
with  the  alternative  architecture.  The  results  of  this  analysis  for 
the  preferred  architecture  are  discussed  In  Section  III  of  this 
report. 

g.  Available  Mid-Term  Clements.  As  noted  earlier  the  network 
elements  used  In  the  mid-term  IAS  must  be  based  upon  available 
technology  In  order  to  permit  an  IOC  of  1983-1988  for  critical 


network  servlets  end  to  permit  the  rapid  replacement  of  existing  AMPEs 
and  ASCs.  Candidate  elements  for  the  mid-term  IAS,  therefore. 

Include  those  elements  of  the  near-term  IAS  architecture  that  can  be 
retained  through  the  mid-term  as  well  as  new  elements  that  could  be 
developed  In  time  for  the  mid-term.  The  candidate  IAS  elements  and 
their  characteristics  are  identified  In  the  following  subsections. 

(1)  Elements  Retained  from  the  Mear-Term.  The  following 
network  elements.  Implemented  prior  to  or  during  the  near-term  will 
be  In  use  In  the  Mid-Term  IAS: 

Packet  Switch  Node  (PSN).  The  PSNs  Installed  In  CONUS 
and  overseas  under  the  AUTOOIN  II  program  will  be  available  In  the 
mid-term  time  frame  for  use  In  the  IAS  backbone.  8ased  on  current 
traffic  projections,  the  PSNs  Installed  In  the  near-term  should  be 
sufficient  to  accoanodate  the  total  IAS  busy  hour  traffic.  The  need 
for  additional  PSNs  to  be  Installed  during  the  mid-term  In  order  to 
support  expansion  Into  the  far- term  and/or  growth  In  the  network  will 
be  based  upon  user  acceptance  and  experience  with  the  Initial 
operational  network. 

Automated  Message  Processing  Exchange  (Near-Term  I-S/A 
AMPE.  AWE,  LOMX/NAVCOMPARS , AF  AMPE,  Streamliner).  As  discussed 
earlier  In  this  section,  most  of  the  MILDEP/Agency  AMPE  equipments 
will  reach  the  end  of  their  useful  service  life  during  the  mid-term 
and  will  be  replaced  by  standardized  Inter-Service/Agency  AMPEs.  The 
MILDEP/Agency  AMPEs  are  therefore,  not  considered  principal  network 
elements  for  the  Mid-Term  IAS.  (Those  MILDEP/Agency  unique  AMPEs 
retained  In  the  mid-term  will  be  treated  the  same  as  other  large, 
automated  AUTOOIN  I terminals  In  the  IAS). 

AUTOOIN  Switching  Center  (ASC).  As  discussed  In  Section 
I.  a principal  objective  of  the  Mid-Term  IAS  Architecture  is  the 
closure  of  the  existing  ASCs  both  In  CONUS  and  overseas.  Therefore, 
ASCs  will  be  retained  In  the  Mid-Term  IAS  Architecture  only  as 
required  to  facilitate  smooth  and  orderly  transition. 

Subscribers.  AUTOOIN  I and  AUTOOIN  II  type  terminals 
and  AUTOOIN  II  host  computers  will  be  supported  through  the  mid-term. 

(2)  New  Elements  Available  for  the  Mid-Term  IAS.  As  part  of 
the  architecture  definition  process  a set  of  generic  network  elements 
that  could  be  developed  and  Implemented  In  the  mid-term  frame  have 
been  defined  by  OCA: 
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Central  Service  Facility  (CSF).  The  CSF  1$  a postulated 
new  centralized  network  service  element  that  would  perform  necessary 
user  support  functions  and/or  network  functions  to  accomplish  message 
delivery  and  provide  needed  user  services.  The  CSF  Is  accessed  via 
the  backbone  network  and  does  not  directly  terminate  subscriber 
equipments.  The  Central  Service  Facility  would  connect  to  the 
network  via  the  PSNs  through  an  AUTC3IN  II  host  computer  (Node  VI 
BSD  Interface.  The  specific  functional  capability  of  the  CSF  Is 
dependent  upon  the  architectural  alternative  selected. 

Inter-Service/Agency  AMPE  (I -S/A  AMPE).  This  new 
element  Is  postulated  as  a standardized  replacement  for  the  existing 
MILDEP/Agency  AMPEs.  It  would  provide  a complete  set  of  agreed  upon 
common  Service/ Agency  AMPE  functions  and  have  provision  for 
accommodating  a limited  number  of  user  unique  functions.  In 
addition,  the  NS/A  AMPE  would  Include  additional  capabilities  that 
permit  It  to  function  In  the  network  Independent  of  other  network 
service  elements  for  most  simple  message  exchange  transactions.  The 
I-S/A  ANPE  would,  therefore,  be  less  dependent  upon  Intermediate 
service  element  processing  than  the  current  AMPEs  are  on  the  ASCs. 

The  I-S/A  ANPE  will  terminate  character  oriented  terminals  of  both 
narrative/record  and  computer  data  character  oriented  users  In  both 
standard  and  user  unique  modes  and  will  connect  to  the  network 
through  a PSN,  an  enhanced  I-S/A  AMPE  or  both.  The  I-S/A  AMPE  will 
be  modular  In  both  hardware  and  software  such  that  great  flexibility 
will  be  available  to  the  Services  and  Agencies  In  tailoring  the  I-S/A 
AMPE  for  each  Installation.  Thus,  number  of  terminations,  throughput 
and  user  unique  capabilities  can  vary  from  site  to  site.  The  basic 
functional  capability  of  the  I-S/A  AMPE  Is  essentially  Independent  of 
the  architectural  alternative  selected. 

Enhanced  Inter-Service/Agency  AMPE  (I-S/A  AMPE (E)). 

This  new  element  Is  postulated  as  a network  service  element  that 
will  be  derived  from  Installed  I-S/A  AMPEs  through  modular 
expansion  of  software  (and  If  necessary  hardware).  The  I-S/A  AMPE 
would,  therefore.  Include  all  of  the  functions  of  an  I-S/A  AMPE  as 
described  above  and  replace  a normal  I-S/A  AMPE  In  the  network  at 
selected  locations.  In  addition,  the  enhanced  I-S/A  AMPEs  In  the 
network  would  provide  the  additional  network  functions  needed  to 
allow  phase  out  of  remaining  ASCs  and  provide  new  functions 
allocated  by  the  architecture.  The  I-S/A  AMPE(E)  would  terminate 
both  narrative/record  and  computer  data  oriented  users  and  connect 
to  the  network  via  an  AUTOOIM  II,  host  computer  (Mode  IV) 

Interface.  The  I-S/A  AMPE(E),  like  the  I-S/A  AMPE,  will  be  modular 
and  thus  provide  the  Services  and  Agencies  great  flexibility  In 
tailoring  the  NS/A  AMPE(E)  to  meet  site  requirements.  The  full 
functional  capability  of  the  I-S/A  AMPE(E)  depends  on  the 
architecture  alternative. 


Common  Family  of  JMJTODIN  Terminals  (CFT).  A new  famll 
of  terminal  equipments  Is  being  defined  by  OCA  as  part  of  the  IASA 
program.  This  common  family  will  Include  a full  range  of  terminals 
from  simple  teletypewriter  to  highly  automated  user  terminals.  The 
functional  capabilities  of  these  terminals  will  be  defined  on  the 
basis  of  user  requirements  and  are  Independent  of  the  architectural 
alternatives  selected. 


h.  Element  Roles.  It  should  be  noted  that  not  all  of  the 
candidate  architectural  elements  are  utilized  In  all  archl tectural 
alternatives.  In  addition,  the  roles  of  some  elements  are 
dependent  upon  the  architectural  alternatives  In  which  they  are 
used.  Finally,  as  noted  above,  the  specific  functional  capability 
of  each  element  Is,  In  many  cases,  dependent  upon  the  archl tectural 
alternative.  The  next  section  of  this  report  describes  the 
alternative  architectures  that  were  considered  for  the  mid-term  IAS 
architecture. 


5.  ALTERNATIVE  MID-TERM  ARCHITECTURES 

In  order  to  Insure  that  all  potential  mid-term  archl tectures  were 
considered,  a number  of  candidate  architectures  were  Identified  as 
part  of  the  technical  analyses  performed  In  support  of  the  IAS 
architecture  definition.  The  set  of  candidate  architectures  was 
generated  through  a sequential  decision  tree  approach  based  on  three 
major  architectural  decision  levels: 

o Selection  of  an  element  set  from  among  the  available  candidate 
elements  discussed  In  paragraph  4 

o Allocation  of  functions  among  the  selected  element  set 

o Consideration  of  specific  configuration/connectivity  options 
within  the  architecture  (e.g. , dual/single  homing  of  nodal 
elements). 

The  candidate  definition  process  resulted  In  the  identification  of 
23  candidate  architectures.  Upon  analysis  of  the  characteristics 
of  the  candidate  architectures.  It  was  determined  that  all 
candidates  could  be  organized  Into  three  major  classes.  Further, 

It  was  determined  that  within  each  major  class  the  differences 
between  archl tectures  were  not  sufficient  to  significantly  Impact 
the  potential  cost  and/or  performance  of  the  resultant  system 
design.  Therefore,  three  final  architectures  were  selected  for 
evaluation  by  choosing  the  most  represented ve  and/or  desirable 
candidate  from  within  each  major  class.  These  three  final 
alternative  architectures  are  described  In  the  following 
subsections.  It  should  be  noted  that  all  three 


architectural  alternatives  utilize  the  packet  switched  node  (PSN)  as 
the  principal  backbone  switching  element  and  the  Interservice/Agency 
AMPE  (NS/A  AMPE)  as  the  principal  access  area  message  processing  and 
communications  concentrator  element.  In  addition,  all  three 
alternative  archl tectures  are  designed  to  provide  the  required  IAS 
user  and  network  services  and  functions  defined  In  Subparagraphs  4 e 
and  4f  respectively. 

a.  Alternative  I 


(1)  General.  This  alternative  represents  a centralized 
architecture  with  little  or  no  hierarchical  structure  In  the  access 
area.  All  network  and  user  services  In  this  alternative  are 
provided  from  a relatively  small  number  of  service  elements  connected 
to  the  backbone  and  accessed  via  the  network. 


(2)  Element  Set.  In  addition  to  the  PSN  and  NS/A  AMPE, 
this  architecture  utilizes  the  Centralized  Service  Facility  (CSF) 
as  the  major  network  element. 

(3)  Functional  Allocation.  As  the  only  available  network 
service  element,  the  CSF  In  this  architecture  will  contain  all 
functions  required  to  support  the  network  and  user  services.  The 
CSF  will,  therefore.  Include  the  ASC  replacement  functions  as  well 
as  any  new  network  functions.  As  noted  earlier,  the  CSF  will  not 
terminate  subscribers. 


(4)  Configuration/Connectivity.  The  backbone  In  this 
alternative  will  consist  of  PSN  switching  nodes  and  CSF  service 
nodes.  The  CSF  will  be  dual  connected  to  PSNs  for  survivability 
as  well  as  to  minimize  service  access  delay.  The  access  area  In 
this  alternative  will  Include  NS/A  AMPEs  and  user  terminals.  In 
general,  computer  data  users  and  host  computers  will  be  connected 
directly  to  PSNs.  Narrative /record  users  will.  In  general,  be 
connected  to  the  back  side  of  the  NS/A  AMPEs. 


b.  Alternative  II. 


(I)  General.  This  alternative  represents  e distributed 
architecture  In  which  user  and  network  services  are  provided  from  a 
common  access  area  element.  This  results  In  a very  flexible 
structure  In  the  access  area  with  services  accessed  both  directly 
and  via  the  backbone  network.  In  addition,  this  architecture 
provides  the  maximum  degree  of  commonality  among  network  elements. 


(2)  Element  Set.  In  addition  to  the  PSN  and  I -S/A  AMPE 
this  alternative  utilizes  the  enhanced  I -S/A  AMPE  (I -S/A  AMPE(E)) 
defined  In  Section  4g. 

(3)  Functional  Allocation.  The  I-S/A  AMPE(E)  provides 
all  terminal  support  and  network  functions  In  this  architecture. 

In  this  alternative  the  I-S/A  AMPE(E)  replaces  the  current  ASCs 
and  also  provides  the  basis  for  all  new  network  services. 

(4)  Configuration/Connectivity.  In  this  alternative  the 
backbone  consists  of  the  PSN  network.  The  access  area  In  this 
architecture  consists  of  the  user  terminals,  I-S/A  AMPEs  and 
I-S/A  AMPE(E)s.  The  I-S/A  AMPE(E)  will  be  connected  directly  to 
the  PSN  with  dual  connection  In  most  cases  for  survivability.  In 
general,  the  I-S/A  AMPE  will  be  connected  to  both  a PSN  and  an 
I-S/A  AMPE(E).  This  will  provide  Increased  survivability  and  allow 
optimal  traffic  routing  for  access  to  needed  services.  Host 
computers  In  this  architecture  will  be  connected  directly  to  PSNs. 

All  other  subscribers  may  be  connected  either  to  PSNs,  I-S/A  AMPE(E)s 
or  I-S/A  AMPEs. 

(5)  Operation.  Most  computer  data  traffic  In  this 
architecture  will  flow  directly  from  source  to  destination  throuqh 
Intermediate  I-S/A  AMPEs,  I-S/A  AMPE(E)s  and  PSNs.  Narrative/record 
traffic  will  generally  flow  through  an  Intermediate  I-S/A  AMPE(E) 
and  will,  therefore,  receive  necessary  terminal  support  and  network 
service  processing  en  route.  All  network  subscribers  will  access 
new  network  services  (e.g.,  teleprocessing,  mailbox)  from  the 
nearest  available  I-S/A  AMPE(E). 

c.  Alternative  III 

(1)  General.  This  alternative  represents  a hybrid 
architecture  between  the  centralized  structure  of  Alternative  I 
and  distributed  structure  of  Alternative  II.  In  this  architecture, 
some  services  are  provided  by  a centralized  backbone  service 
element  and  some  services  are  provided  by  a distributed  access 
area  element. 


(2)  Element  Set.  In  Addition  to  the  PSN  and  I-S/A  AM PE 
this  architecture  employs  both  a Centralized  Service  Facility  (CSF) 
and  an  I-S/A  AMPE(E). 

(3)  Functional  Allocation.  In  this  alternative  the  ASC 
replacement  functions  (both  terminal  support  and  network  service) 
are  allocated  to  the  I-S/A  AMPE(E)  located  in  the  access  area.  The 
functions  necessary  to  provide  new  network  services  are  allocated 
to  the  CSF  located  in  the  backbone. 

(4)  Configuration/Connectivity.  The  backbone  In  this 
alternative  consists  of  the  PSN  network  and  a small  number  of  CSFs. 
The  CSFs  are  dual  connected  directly  to  the  PSNs  for  survivability 
and  minimum  access  delay.  The  access  area  In  this  alternative 
Includes  subscriber  terminals,  I-S/A  AMPEs  and  I-S/A  AMPE(E)s. 

The  access  area  connections  in  this  architecture  are  similar  to 
those  in  Alternative  II. 

(5)  Operation.  The  operation  of  this  alternative  Is 
strongly  affected  by  the  separation  of  traffic  support  functions. 
Depending  on  the  type  of  traffic  in  a particular  transaction,  the 
data  flow  may  be  either  directly  from  source  to  destination  via 
the  PSN  backbone  network  or,  depending  on  the  services  required, 
through  the  appropriate  backbone  or  access  area  service  element. 
Traffic  routing  and  data  flow  In  this  alternative  are  therefore 
sometrfiat  more  complex  than  In  the  other  two  alternatives. 

d.  Summary.  The  basic  configuration,  nodal  element  types,  and 
functional  allocation  for  the  three  alternative  architectures  are 
summarized  In  Figure  8.  This  figure  presents  a greatly 
simplified  representation  of  each  architecture.  As  discussed 
earlier  In  this  section,  these  three  alternatives  represent  the 
three  major  classes  of  archl tec tu res  applicable  to  the  IAS  mid-term, 
Each  of  these  architectures  provides  the  required  mid-term  IAS 
services  and  functions  and  Is  consistent  with  the  constraints  and 
anticipated  operating  environment  of  the  mid-term.  In  addition, 
each  of  these  alternative  architectures  represents  a significant 
departure  from  the  Near-Term  IAS  Architecture  described  In 
Section  II,  paragraph  1. 


6.  EVALUATION  OF  ALTERNATIVES 


Si  net  tht  eventual  performance  of  any  tyttM  is  difficult  to 
measure  «t  such  an  early  stage  of  architectural  definition;  and, 
since  detailed  system  performance  requirements  based  on  future 
user  applications/ needs  cannot  be  specified  until  much  later  In 
the  system  definition/design  cycle;  and  since  each  alternative 
architecture  Is  capable  of  meeting  the  anticipated  future 
performance  requirements  through  design  tradeoffs  within  the 
state-of-the-art;  the  differences  between  alternative  architectures 
were.  In  many  cases,  measured  In  terms  of  the  difficulty  or 
complexity  of  meeting  performance  objectives  In  given  areas  based 
on  Inherent  architecture  characteristics.  Examples  of  such 
characteristics  are: 

o The  number  of  nodal  and  transmission  delays  that  must  be 
encountered  from  user  to  user/ service  element 
o The  number  of  different  nodal  elements  contained  In  the 
network  and  the  degree  of  commonality  among  elements 


In  order  to  determine  the  preferred  Mid-Term  IAS  Architecture, 
the  three  alternative  architectures  described  In  Paragraph  S were 
evaluated  with  respect  to  both  technical  and  cost  factors.  This 
evaluation  was  based  on  a series  of  quantitative  and  qualitative 
technical  analyses  performed  In  support  of  the  IAS  architecture 
definition.  In  order  to  provide  a high  degree  of  confidence  In 
the  final  results  of  the  evaluation,  the  general  approach  to 
alternative  evaluation  was  based  on  the  following  guidelines: 

o Evaluation  on  the  basis  of  comparative/relative  performance 
vice  absolute  performance  estimates 

o Application  of  quantitative  analytic  techniques  wherever 
possible  and  appropriate 

o Consideration  of  all  relevant  factors  In  subjective/ 
qualitative  analyses 

o Careful  documentation  of  factors  considered  and  basis  for 
subjective  decision 

o Thorough  review  of  analysis  methods  and  results  by 
cognisant  OCA/DCEC  personnel 


o The  number  of  operations  required  to  complete  a message 
transfer  Including  Intermediate  processing 

o The  number  of  elements  avail  able/ required  for  user 
connection/service  access. 

The  technical  analyses  performed  In  this  evaluation  process  are 
documented  In  Appendix  B,  C and  D.  The  next  subsection  describes 
the  evaluation  criteria  used  In  these  analyses. 

a.  Evaluation  Criteria.  Five  major  evaluation  criteria  were 
used  for  the  evaluation  of  alternative  architectures.  Within 
each  criterion  anywhere  from  4 to  10  subcriteria  were  considered. 
Within  each  subcriterion,  a number  of  factors  were  considered. 

The  following  paragraphs  define  each  major  criterion  and  Identify 
the  subcriteria  and  factors  considered  In  the  evaluation. 

(1)  Operational  Effectiveness.  This  criterion  addresses 
the  relative  efficiency  and  effectiveness  of  an  architecture  for 
providing  the  required  functional  capability.  The  subcriteria 
used  In  this  category  were  speed  of  service,  user  motivated 
Interfaces,  transmission  efficiency,  system  motivated  functions, 
security  and  adaptability  to  overseas.  The  factors  considered  In 
the  subcriteria  were:  speed  of  service  by  traffic  type  (e.g.. 
Interactive,  query/response,  key  distribution,  mailbox); 

Interface  complexity  for  access  to  and  interaction  with  network 
services;  transmission  overhead  by  network  function  (e.g., 
addressing,  normal  routing,  CARP  routing,  flow  control,  error 
control,  system  control);  complexity  of  system  motivated 
functions  (e.g.,  system  control,  accountability);  ability  to  meet 
security  objectives;  ability  to  support  mobile  terminals,  ability 
to  utilize  mobile/transportable  elements  based  on  element  size 
and  potential  user  Impact;  risk  of  overseas  deployment  associated 
with  PSN,  CSF,  I -S/A  AMPE(E)  and  size  of  CONUS/overseas  trunks. 

(2)  Flexibility.  This  criterion  measures  the  ability  of 
an  architecture  to  accommodate  change.  Ten  subcriteria  were 
defined  In  two  major  areas,  adaptability  and  expandability. 
Adaptability  refers  to  the  ability  of  an  architecture  to 
accommodate  changes  In  the  demand  or  utilization  of  Its  planned 
capabilities.  Expendabll Ity  measures  the  ability  of  the 
architecture  to  accomodate  additional  requirements.  The 
subcriteria  used  Include:  traffic  type  adaptability,  external 
Interface  adaptability,  network  service  adaptability,  subscriber/ 
traffic  distribution  adaptability,  subscriber  expandability, 
protocol  expandability,  service  expandability,  control  function 
expandability,  traffic  expandability  *nd  external  Interface 
expandability.  Other  factors  considered  within  these 
subcriteria  Include:  the  Impact  of  changes  In  the  amount  of  bulk 
versus  narrative  traffic,  secure  versus  non-secure  traffic,  PSN 


versus  I-S/A  AMPE  connected  subscribers,  local  versus  remote 
traffic;  the  Impact  of  Increasing  the  number  and  types  of 
subscribers,  link  protocols,  user  level  protocols,  network  level 
protocols,  and  services. 
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(3)  Survivability/ Aval lablllty/Supportablllty.  This 
criterion  considers  the  Inherent  ability  of  an  architecture  to 
provide  the  required  service  In  both  normal  and  hostile  operating 
environments.  The  subcriteria  defined  In  this  category  Include: 
the  effect  of  nodal /link  failures  on  system  operation,  the  ability 
of  the  architecture  to  protect  against  nodal/llnk  failures,  the 
ability  of  the  architecture  to  recover  from  failures  and  the 
supportablllty  of  the  architecture.  The  factors  considered  within 
this  criterion  Include  the  potential  loss  of  service  and  access, 
the  complexity  of  CARP  ( source/ network ) , dual  honing  flexibility, 
ability  to  support  redundant  nodes,  number  of  elements  requiring 
support  and  degree  of  commonality  among  elements. 

(4)  Transition.  This  criterion  considers  the  ability  of 
an  architecture  to  evolve  from  the  near-term  to  and  beyond  the 
specific  mid-term  architecture.  Subcriteria  Identified  within  this 
area  were  development  risk,  user  Impact,  ease  of  Implementation, 
and  potential  for  continued  evolution.  The  factors  considered 
Include:  hardware  and  software  development  risks,  continuity/ 
disruption  of  service,  availability  of  required  elements,  extent  of 
modifications  required  to  existing  elements,  consistency  with 
future  long-term  architectural  objectives  (e.g.,  satellite 
broadcast  backbone.  Integrated  voice  and  data). 

(5)  Cost.  This  criterion  measures  the  potential  of  each 
architecture  for  reducing  the  cost  of  ownership  and  operation  of 
the  Mid-Term  IAS.  Major  cost  elements  considered  as  subcriteria 
within  this  category  are  transmission  costs,  nodal  element 
acquisition  cost,  and  operation  and  maintenance  cost.  The  cost 
factors  considered  Include  Initial  and  recurring  costs  associated 
with:  backbone  trunks  and  access  area  communications  facilities, 
hardware  and  software  Investment  costs,  and  personnel  support  and 
training  costs. 

b.  Evaluation  Results.  Based  upon  the  results  of  the  evalu- 
ation process  the  preferred  architecture  for  the  Mid-Term  IAS  will 
be  based  upon  Alternative  II.  (Also  see  Section  III,  paragraph  5 
for  additional  comparison  of  the  alternatives.)  This  alternative 
was  determined  to  be  preferred  to  each  of  the  other  alternatives  In 
three  of  the  five  major  evaluation  criteria  Including  the  two 
technical  criteria  which  are  considered  most  Important  for  the 
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Mid-Term  IAS  - transition  and  survlvablllty/aval  lability/ 
supportablllty.  A principal  characteristic  of  this  architecture 
which  led  to  Its  selection  Is  the  consol Idatlon/lntegratlon  of 
network  and  user  motivated  functions  Into  a single  service  element 
based  upon  the  currently  planned  Inter- Service/Agency  AMPE  program. 
This  consol Idatlon/lntegratlon  provides  significant  potential 
benefits  In  both  cost  and  performance  and  contributes  materially  to 
the  ease  of  transition  from  near-term  to  the  mid-term  network 
architecture.  The  preferred  architecture  as  well  as  the  two 
alternatives  are  described  In  more  detail  In  the  next  section. 
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SECTION  III 


MID-TERM  ARCHITECTURE 


1.  INTRODUCTION 

The  preferred  architecture  for  the  Mid- Tern  Integrated  AUTOOIN 
System  (IAS)  Is  based  on  the  selection  of  Alternative  II.  This 
architecture  meets  all  anticipated  Mid-Term  IAS  operational 
requirements  and  provides  a substantial  Improvement  over  the 
near-term.  The  preferred  architecture  provides  significant 
advantages  over  other  archl tectures  In  terms  of  transition 
capabilities  (both  for  the  mid-term  and  beyond), 
survlvablllty/avallablllty/supportablllty  and  cost. 

The  preferred  architecture  for  the  Mid-Term  IAS  Is  described 
fully  In  the  following  paragraphs.  Alternative  architectures  are 
described  In  terms  of  their  differences  from  the  preferred 
architecture  In  subsequent  paragraphs.  This  method  of  presentation 
was  selected  In  order  to  reduce  the  unnecessary  redundancy  between 
architecture  descriptions  as  well  as  to  highlight  the  differences 
between  architectural  alternatives.  The  final  paragraph  In  this 
section  provides  the  summary  comparison  of  the  three  architectures 
and  the  basis  for  recommendation  of  the  preferred  architecture. 

2.  DESCRIPTION  OF  PREFERRED  ARCHITECTURE 

a.  Elements.  The  preferred  Mid-Term  IAS  Architecture  will  use  a 
combination  of  existing  and  newly  developed  network  elements.  The 
major  elements  of  the  architecture'  and  their  appllcatlon/role  In  the 
architecture  are  discussed  In  the  following  subparagraphs. 

(1)  Packet-Switched  Node  (PSN).  The  preferred  architecture 
will  use  the  PSN  (described  In  Section  II,  l,  c (1))  as  the  backbone 
switching  element  for  the  Mid-Term  IAS.  The  AUTOOIN  II  PSN  will  not 
require  any  anticipated  modifications  to  fill  this  role.  As 
discussed  In  Appendix  E,  the  security  subsystem  (access  control  and 
key  variable  distribution)  can  be  Implemented  In  a separate  host 
computer  connected  to  the  PSN  via  the  network  for  ease  of  transition. 
The  PSN  will,  therefore,  not  be  affected  by  the  conversion  from  link 
to  end-to-end  encryption.  The  PSN  of  the  Mid-Term  Architecture  will 
require  the  TAC  capability  to  terminate  character  oriented  ‘ 
subscribers.  In  addition,  the  ability  of  the  PSH  to  terminate 
AUTOOIN  I,  Mode  I subscribers  through  use  of  a predefined  segment 
leader  (cut-through)  will  be  retained  In  the  Mid-Term.  No  changes 


are  anticipated  to  the  normal  routing  procedures  Implemented  In  the 
PSN.  New  contingency  routing  schemes  will  be  accomplished  In  the 
preferred  architecture  within  other  network  elements  such  as  the 
I-S/A  AM  PE.  For  further  description  of  the  AUTODIN  IT  PSNs,  see 
Reference  B. 


(2)  Inter-Service/Agency  AMPE  (I-S/A  AMPE).  The  I-S/A  AMPE 
Is  used  In  the  preferred  architecture  as  both  a local  message 
processing  service  element  and  a communications  network  front  end.  A 
simplified  block  diagram  of  the  I-S/A  AMPE  Is  Illustrated  In  Figure 
9.  As  Indicated,  the  I-S/A  AMPE  will  Include  the  same  SIP  and 
TCP  functions  contained  In  a PSN  TAC  and  will  function  as  a remote 
TAC  to  the  PSN  (see  PSN  subparagraph  above).  In  addition,  the  I-S/A 
AMPE  will  Include  THP  and  terminal  control  functions  needed  to 
Interface  AUTODIN  II  type  subscribers,  as  well  as  the 
store-and- forward  processing  functions  needed  to  Interface  AUTODIN  I 
terminals.  In  addition  to  terminating  both  AUTODIN  I and  AUTOOIN  II 
type  subscribers,  the  I-S/A  AMPE  will  provide  the  terminal  support 
functions  (PLA/RI  conversion,  format  validation,  etc.)  needed  to 
support  user  terminals  that  require  such  services.  In  order  to  fill 
Its  role  as  a network  front  end,  the  NS/A  AMPE  will  Incorporate 
network  protocols  and  processing  capabilities  that  will  permit  most 
simple  direct  terminal-to-termlnal/host  transactions  to  take  place 
without  the  Involvement  of  other  higher  level  service  elements  except 
the  PSN  switches.  As  a result  of  this  capability,  the  NS/A  AMPEs 
will  significantly  contribute  to  more  efficient  use  of  backbone 
facilities  and  Improve  survivability.  In  Its  role  as  a network  front 
end,  the  I-S/A  AMPE  will  forward  traffic  from  subscribers  requiring 
higher  level  service  to  the  appropriate  network  service  elements. 
However,  unlike  the  current  system  of  dedicated  "home"  service 
elements,  the  I-S/A  AMPE  will  be  able  to  forward  traffic  to  any 
element  In  the  network  capable  of  providing  the  service.  This 
capability  will  allow  dynamic  laod  balancing  among  the  higher  level 
elements  (I-S/A  AMPE(E))  In  normal  conditions,  and  provide  a method 
of  contingency  recovery  In  the  event  of  loss  of  a service  element. 

The  I-S/A  AMPE  will  replace  all  current  AMPEs  but  not  necessarily  on 
a one- for- one  basis.  Because  of  Its  standardized 
Implementatl on/operation,  the  I-S/A  AMPE  will  satisfy  all 
service/agency  requirements.  This  will  allow  consolidation  of 
current  AMPE  locations  with  no  reduction  In  service.  Finally,  the 
I-S/A  AMPE  will  provide  the  basis  for  network  expansion  through 
upgrade  of  Installed  I-S/A  AMPEs  to  enhanced  I-S/A  AMPE(E) 
configurations.  Based  on  a modular  transportable  software 
development  approach.  It  Is  anticipated  that  any  I-S/A  AMPE  can  be 
converted  to  enhanced  status  after  Installation.  The  I-S/A  AMPE 
family  of  equipments  Is,  therefore,  the  key  to  both  Implementation 
and  continued  evolution/ growth  of  the  IAS  network. 


(3)  Enhanced  Intar-Servlct/Agency  AMPE  (I -S/A  AMPE(E)).  In 
the  preferred  architecture,  the  I-S/A  ANPE(E)  will  fill  two  distinct 
rolos.  First,  It  will  function  as  a normal  I-S/A  AMPE  for  Its 
locally  connected  subscribers.  In  tMs  rola  It  will  provide  local 
terminal  support  and  message  processing  functions  and  act  as  the 
network  front  end.  Secondly,  the  I-S/A  AHPE(E)  will  serve  as  a 
network  service  element.  In  this  role  the  I-S/A  AMPE(E)  will  provide 
network  services  to  both  locally  connected  and  remote  access 
subscribers  throughout  the  network.  As  a network  service  element, 
the  I-S/A  AMPE(E)  will  support/augment  the  capability  of  the  lower 
level  I-S/A  AMPE  and  terminal  elements  by  performing  message/data 
processing  services  that  require  processing  and/or  data  storage 
capacity  beyond  that  available  In  the  lower  level  elements.  Typical 
services  In  this  category  Include:  special  code/format  conversion; 
message  exchange  with  systems  outside  IAS;  mailbox  storage;  file 
storage,  update,  and  retrieval;  telecommunications  conference  control 
and  record  keeping.  Shared  network  use  of  these  I-S/A  AMPE(E) 
capabilities  will  significantly  reduce  the  processing  and  storage 
requirement  of  the  I-S/A  AMPE  and  terminal  equipments.  This  in  turn 
should  significantly  reduce  the  total  network  acquisition  and 
operating  cost  to  provide  a given  level  of  network  service.  The 
I-S/A  AMPE(E)  will  be  developed  under  the  same  program  as  the  I-S/A 
AMPE  and  will  share  Its  basic  software  modules.  The  block  diagram 
contained  In  Figure  9,  therefore.  Is  also  applicable  to  the  I-S/A 
AMPE(E).  The  I-S/A  AMPE(E)  will,  of  course.  Include  additional 
software  modules,  additional  hardware  processing  and  storage 
capacity,  and  additional  communications  Interface  hardware/software 
As  Indicated  previously,  the  I-S/A  AMPE(E)  Installations  will  In  many 
cases  be  accomplished  by  retrof 1 t/upgrade  of  previously  Installed 
I-S/A  AMPEs. 

(4)  Subscriber  Terminals.  As  previously  stated.  It  Is 
expected  that  the  Mid-Term  IAS  will  have  to  support  all  existing 
types  of  AUTODIN  I and  planned  AUTOOIN  11  terminals.  It  Is  also 
expected  that  terminals  with  additional  capabilities  will  be 
Introduced  In  the  Mid-Term  as  part  of  the  Common  Family  of  AUTOOIN 
Terminals.  Although  Increased  capability  In  some  terminals  will  not 
relieve  the  network  of  supporting  the  remainder  of  less  capable 
terminals.  It  can  reduce  the  processing  load  on  the  network  and 
reduce  the  dependence  of  the  terminals  on  other  network  elements.  A 
summary  of  anticipated  Mid-Term  subscriber  terminal  characteristics 
Is  shown  In  Table  IV. 

b.  Configuration/Connectivity.  The  basic  configuration  of 
network  elements  In  the  preferred  architecture  Is  Illustrated  In 
Figure  10.  Figure  11  Illustrates  all  generic  single 


TABLE  IV.  ANTICIPATED  MID-TERM  IAS  TERMINAL  CHARACTERISTICS 


TYPES  - All  AUTOOIN  I and  AUTOOIN  II  types  plus  common  family  of 
terminals  to  Include  mort  Intal  11  gant/capable  tamlnals 


PROTOCOLS  - All  AUTOOIN  I and  AUTOOIN  II  protocols  plus  additional 
unlqua  link  protocols  (e.g.,  AMPE  usar  protocols)  and  new  and-to-and 
protocols  (a.g..  Virtual  Massage  Protocol)  I-S/A  AMPE-to-I-S/A  AMPE 


COOES  ? ASCII  and  ITA#2  (others  transparent) 


FORMATS  - AUTOOIN  II  Segment  Formats.  JAflAP  128,  ACP  126/127,  001 
100/103,  00-173 
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connections  (both  preferred  and  alternative)  between  elements  In  more 
detail.  As  Indicated  In  this  diagram,  AUTOOIN  I type  subscribers 
(Including  AMPEs)  connected  to  PSNs  will  enter  messages  In  AUTOOIN  I 
formats  via  the  PSM  TAC  and  all  of  their  traffic  will  be 
automatically  routed  (cut- through)  to  a designated  I-S/A  AMPE(E)  for 
processing.  Since  the  PSNs  do  not  process  the  AUTOOIN  I Header 
containing  precedence  and  security  format  elements,  all  cut- through 
traffic  will  be  handled  at  the  highest  level  precedence  and  security. 
For  this  reason,  direct  connection  of  AUTOOIN  I type  subscribers  to 
I-S/A  AMPEs  or  I-S/A  AMPE(E)s  Is  preferred  to  PSN  connection. 

Although  not  shown  In  Figure  11,  terminals  may  be  homed  either 
singly  or  dually  to  any  combination  of  the  nodal  element  types,  i.e., 
PSN,  NS/A  AMPE(E),  or  I-S/A  AMPE. 

I-S/A  AMPEs  may  be  connected  to  PSNs  or  I-S/A  AMPE(E)s  and 
can  be  dual  connected  to  one  or  both  of  those  element  types.  As 
discussed  previously,  I-S/A  AMPEs  may  exchange  message  traffic 
without  routing  It  through  an  I-S/A  AMPE(E).  Since  some  I-S/A  AMPE 
traffic  will  require  routing  to  an  I-S/A  AMPE(E)  for  service  and  some 
will  be  routed  directly  through  the  PSN  backbone,  the  preferred 
connectivity  for  an  I-S/A  AMPE  will  be  dual  connection  to  both  a PSN 
and  an  I-S/A  AMPE(E).  Depending  on  the  specific  communities  of 
Interest  served  by  an  I-S/A  AMPE  and  the  proportions  of  traffic 
types.  It  will  be  possible  to  connect  (singly  or  dually)  an  I-S/A 
AMPE  to  either  one  of  those  element  types. 

I-S/A  AMP£(E)s  will  access  the  network  directly  via  a PSN. 
They  will  normally  be  dual  connected  to  PSNs  for  survivability. 

Tactical  and  allied  system  Interfaces  in  AUTODIN  I subscriber 
modes  will  have  the  same  connection  options  as  AUTODIN  terminals,  and 
for  the  same  reasons,  connection  of  AN/TYC-39  and  NICS  TARE  relays  to 
an  I-S/A  AMPE  or  I-S/A  AMPE(E)  Is  preferred.  The  Interface  between 
I-S/A  AMPE  and  I-S/A  AMP£(E)s  will  be  Mode  VI. 

I-S/A  AMPEs  will  not  normally  be  directly  Interconnected,  but 
for  contingencies  may  connect  using  Mode  I or  Mode  VI  protocol.  The 
Interconnectivity  of  all  network  elements  Is  summarized  In  Figure  12. 

The  connectivity  options  offered  by  the  architecture  allow 
flexibility  for  overseas  deployment.  In  general,  the  backbone  IAS 
network  will  be  extended  by  locating  PSNs  overseas.  For  transition 
purposes,  however,  the  required  services  can  also  be  provided  to 
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overseas  users  before  deploying  PSNs  oversees  by  connecting  oversees 
I— S/A  AM  PCs  end/or  NS/A  AMPE(E)s  directly  to  conus  PSNs. 
AUernetlves  for  oversees  Implementation  ere  further  discussed  In 
Section  IV,  TRANSITION. 


c.  Protocols.  The  Implementation  of  the  preferred  Mid-Tern 
* Architecture  will  require  the  development  of  et  leest  one  new  network 

level  protocol.  This  protocol,  celled  the  Vlrtuel  Messege  Protocol 
(VMP)  will  support  direct  exchange  of  messege  Infoneetlon  emong  I-S/A 
AMPEs  end  between  NS/A  AMPEs  end  NS/A  AMPC(E)s  connected  vie  the  I 

PSN  beck bone.  Addltlonel  network  level  end  link  level  protocols  ney 
be  identified  In  the  process  of  further  defining  the  Mid-Term  network  > 

( t services  end  operetlng  procedures.  However,  these  new  protocols  will 

be  Implemented  only  In  the  new  IAS  Mid-Term  elements.  No  new 
protocols  ere  required  In  existing  elements  to  support  the  preferred 
erchltecture.  This  Is  e slgnlflcent  considered  on  In  the 

evolutlonery  development  of  the  Mid-Term  IAS  network  \ 

u The  entlclpeted  link  end  network  level  protocols  end  their 

use  In  the  preferred  erchltecture  ere  discussed  further  In  the 
following  subperegrephs. 

(1)  Link  Protocols.  The  link  level  protocols  entlclpeted 
between  Mid-Term  elements  are  suamerlzed  In  Floure  13.  i 


(2)  Network  Level  Protocols.  The  Mid-Term  Architecture 
mekes  use  of  the  protocol  leyers  defined  for  AUTOOIN  II.  The  new  IAS 
elements,  the  I-S/A  AMPE  end  I-S/A  AMPE(E),  will  operete  through  the 
network  using  host- type  protocols.  I.e.,  they  will  employ  the  Segment 
Interfece  Protocol  (SIP)  end  Trensmlsslon  Control  Progrem  (TCP) 
defined  In  Reference  B.  In  addition,  they  will  use  e Vlrtuel  Messege 
Protocol  (VMP)  for  exchenglng  messege  trefflc  through  the  packet 
network.  The  VMP  will  Include  functions  necessary  for  routing  end 
accountability  of  narrative/record  trefflc  (most  of  which  ere 
presently  provided  by  the  ASCs),  such  as  message  acknowledgements, 
rejections,  cancellations,  service  messege  generation,  end  messege 
control  block  functions.  The  network  level  protocols  required  by  the 
Nld-Tem  IAS  Architecture  ere  defined  In  the  following  subperegrephs. 

Switch- to- Switch  Protocols.  SwItch-to-SwItch  protocols 
ere  defined  for  AUTOOIN  II  PSNs  to  accomplish  routing,  accountability 
end  flow  control  between  local  end  source/destination  packet 
switches.  These  protocols  ere  not  changed  by  the  Mid-Term 
Architecture. 
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Figure  13.  Preferred  Architecture  Link  Protocols 


Host-to-Swl tch  Protocol.  The  protocol  used  between  PSNs 
end  AUTOOIN  II  hosts  end  between  PSNs  end  NS/A  AMPEs  end  I -S/A 
AMPE(E)s  1$.  the  Segment  Interfece  Protocol  (SIP),  eccompl 1 shed 
through  the  exchenge  of  blnery  segment  leeders. 

Host-to-Host  Protocols.  Host-to-Host  protocols  refer  to 
the  generel  set  of  protocols  used  between  host  computers  or  eutometed 
messege  exchenges  communlcetlng  through  the  network.  They  Include 
the  Trensmlsslon  Control  Protocol  (TCP)  end  other  host-specific 
protocols.  The  I-S/A  AMPEs  end  I-S/A  AMPE(E)s  will  use  the  TCP  for 
communlcetlng  through  the  network  with  host  computers,  other  I-S/A 
AMPEs  end  NS/A  AMPE(E)s,  end  PSN  Termlnel  Access  Controllers  (TAC). 
In  eddltlon,  the  NS/A  AMPEs  will  use  the  new  Vlrtuel  Messege 
Protocol  (VHP)  for  exchenglng  nerretlve/record  trefflc  among 
themselves  end  with  other  hosts  or  eutometed  messege  processing 
feci 11  ties  which  employ  the  VMP  protocol. 

Terminal -to-Host  Protocols.  Termlnal-to-Host  protocols 
refer  to  the  generel  set  of  protocols  which  el  low  termlnel s to 
Interect  with  hosts  or  messege  processing  elements.  The  standerd 
AUTOOIN  II  Terminal- to-Host  Protocol  ( THP ) will  be  used  In  the 
Mid-Term  Architecture  for  this  purpose.  The  THP  supports  termlnal- 
to- term Inal  end  terminal -to- process  transactions  by  making  the 
various  terminals  end  processes  appear  as  similar  as  possible  to 
users.  These  transactions  require  Interaction  between  source  and 
destination  THPs  end  between  the  THPs  end  the  terminals  end  host 
processes.  In  AUTOOIN  II,  the  THP  Is  Implemented  In  host  computers 
end  PSN  TACs.  Since  the  I-S/A  AMPEs  end  the  I-S/A  AMPE(E)s  will 
provide  a TAC  capability  for  AUTODIN  II  type  subscribers,  they  will 
also  Implement  the  THP.  The  elements  which  directly  terminate 
subscribers  must  also  Incorporate  terminal  handlers,  or  terminal 
control  protocols  tailored  to  the  characteristics  of  the  specific 
terminals. 


User-to-User  Protocols.  User-to-user  protocols  are  the 
procedures  effected  between  end  users  of  the  network  (where  the  end 
users  may  be  terminal /system  operators  or  software  processes)  through 
exchange  of  control  Information  and  message  format.  The  packet 
switch  network  and  the  protocol  levels  described  above  are 
transparent  to  the  user-to-user  protocols.  User-to-user  protocol 
Includes  such  functions  as  user  Interaction  with  a host  software 
process  and  end-to-end  security  functions.  Message  format 
Instructions  for  message  distribution  and  handling  by  I-S/A  AMPEs, 
NS/A  AMPE ( E ) s , AMPEs.  and  terminals,  such  as  transmission  control/ 
release  codes,  office  symbols,  flagwords  or  references  are  also 
considered  within  the  class  of  user-to-user  protocols  for  the 
purposes  of  this  protocol  definition. 
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Figures  14  and  15  show  examples  of  the  application 
of  the  classes  of  protocols  described  above.  Figure  14  shows  the 
primary  layers  of  protocols  required  for  a transaction  between  an 
I-S/A  AMPE  connected  AUTOOIN  II  type  terminal  and  a PSN  connected 
host  computer.  (Additional  protocol  layers  exist  which  are  not  shown 
In  this  and  other  diagrams,  such  as  originating  terminal  to 
destination  host  and  originating  host  to  destination  PSN.  Also  not 
shown  are  link  level  protocols.)  In  this  example,  the  TAC  equivalent 
functions  In  the  I-S/A  AMPE  provide  host  level  protocols. 

Figure  IS  shows  the  network  protocols  for  an  AUTOOIN 
I type  transaction  between  I-S/A  AMPE  or  I-S/A  AMPE(E)  connected 
subscribers.  In  this  case  the  Virtual  Message  Protocol  (VMP)  Is 
employed  between  the  I-S/A  AMPEs  or  I-S/A  AMPE(E)s  to  control  the 
exchange  of  narrative/record  messages  through  the  network.  A 
user-to-user  level  protocol  Is  shown  between  the  I-S/A  AMPEs  or  I-S/A 
AMPE(E)s  which  Includes  message  format  processing  such  as 
distribution  Instructions.  The  THP  used  for  AUTOOIN  II  type 
transactions  does  not  apply  In  this  case. 

d.  Functional  Allocation.  The  allocation  of  functions  to 
network  elements  In  the  preferred  architecture  Is  summarized  In 
Figure  16.  In  order  to  Illustrate  the  evolutionary  transition 
required  from  the  near-term  to  the  mid-term.  Figure  16  Includes 
the  current  near-term  AUTOOIN  elements  and  Illustrates  their 
functional  capabilities.  As  noted  In  Section  II,  the  functions 
required  for  the  basic  AUTOOIN  I narrative/record  message  transfer 
service  can  be  generally  categorized  as  subscriber  support  functions 
(e.g.,  code  and  format  conversion,  message  retrieval)  and  network 
functions  (e.g.,  multiple/collective  routing).  In  the  preferred 
architecture,  the  subscriber  support  functions  are  allocated  to  the 
I-S/A  AMPE  because  they  are  most  effectively  performed  at  a point 
near  the  subscribers,  and  because  many  of  these  functions  are  already 
performed  In  the  existing  AMPEs.  In  addition,  the  I-S/A  AMPE  Is  also 
assigned  the  AUTOOIN  II  terminal  access  functions  and  a Mode  VI 
host-type  Interface  to  the  PSN  both  to  provide  flexibility  for 
subscriber  termination  to  the  network,  and  to  ensure  an  efficient, 
potentially  high  speed,  network  access.  In  this  architecture,  the 
AUTOOIN  I network  ( ASC  replacement)  functions  as  well  as  the 
functions  required  to  support  new  IAS  services  are  allocated  to  the 
I-S/A  AMPE(C).  Since  the  I-S/A  AMP£(E)  Is  a modular  enhancement  of 
the  I-S/A  AMPE,  It  also  has  all  the  capabilities  of  the  I-S/A  AMPE. 

Ourlng  the  mid-term,  the  IAS  Architecture  must  support  both 
link  encrypted  and  end-to-end  encrypted  users.  For  link  encrypted 
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Figure  14.  IAS  Network  Protocols,  Terminal /Host  Transection 
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users  the  NS/A  AMPE  and  NS/A  AMPE(E)  In  the  preferred  architecture 
will  provide  encrypt1on*and  decryption  functions  and  the  security 
processing  functions  of  format  and  Input/output  line  validation. 

There  are  several  options  for  the  allocation  of  end-to-end  security 
functions  In  the  preferred  architecture.  Including  their  allocation 
to  the  NS/A  AMPE(E)  or  PSN.  These  options  are  discussed  In  Appendix 
E. 

As  previously  discussed,  the  Mid-Tens  Architecture  will  have 
to  support  the  range  of  existing  AUTOOIN  I and  AUTOOIN  I!  user 
terminals,  Including  unintelligent  terminals.  Although  these 
terminals  will  exist  throughout  the  mid-term,  a new  standard  family 
of  AUTOOIN  terminals  with  additional  capabilities  Is  planned  for 
development  for  use  ,1  n the  Mid-Term.  The  analysis  and  evaluation  of 
architectures  performed  as  part  of  the  IAS  definition  revealed 
several  major  functions  that  should  be  considered  for  Implementation 
within  the  range  of  future  terminals.  Some  of  the  major  functions 
identified  are: 

o Generation  of  network  logical  addresses  and  conversion  between 
logical  addresses,  plain  language  addresses  and  routing 
Indicators 

o Recognition  and  appropriate  addressing  of  traffic  that 
requires  processing  by  a service  element 

o Performance  of  end-to-end  terminal  security  functions 

o Conversion  of  user  unique  formats  to  common  network  formats 

o Automatic  message  preparation  assistance  (prompting,  editing, 
etc.) 

o Automatic  message  distribution 

o Direct  Interface  with  PSNs  using  Mode  VI  host-type  protocols 
and  virtual  Message  Protocol 

The  anticipated  results  of  performing  these  functions  In  terminals 
vice  other  elements  would  be  to  relieve  the  network  of  local 
processing  requirements,  reduce  the  dependence  of  the  terminals  on 
other  network  elements  ( 1 .e. , to  facilitate  mobility/ survivability) 
and  to  Improve  the  response  time  of  the  user-to-network  Interface. 
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e.  Network  Services.  Section  II-4.e  describes  the  candidate 
network  services  currently  defined  for  the  Mid-Term  IAS.  Any  or  all 
of  these  services  can  be  provided  by  the  Mid-Term  IAS  Architecture  as 
required.  Implementation  of  certain  of  these  services  may  require 
changes  to,  or  development  of,  policies,  standards,  and  procedures  to 
facilitate  their  use.  The  following  subparagraphs  Illustrate  how 
these  services  would  be  Implemented  In  the  preferred  architecture. 

(1)  Narrative/Record  Message  Transfer.  Subscribers  connected 
to  I-S/A  AMPEs  or  I-S/A  AMPE(E)s  will  receive  this  service  directly 
from  those  elements.  Since  the  I-S/A  AMPE(E)  will  have  more 
capability  than  the  I-S/A  AMPE,  subscriber  traffic  requiring  special 
processing  will  be  forwarded  from  the  I-S/A  AMPE  to  the  I-S/A  AMPE(E) 
for  additional  narrative/ record  service.  All  traffic  from 
subscribers  directly  connected  to  PSNs  and  operating  In  AUTODIN  I 
modes  will  be  "cut-through*  to  an  I-S/A  AMPE(E)  for  processing  (AMPEs 
will  normally  be  directly  connected  to  an  I-S/A  AMPE(E)  but  may  be 
"cut-through"  to  an  I-S/A  AMPE(E)  via  a PSN).  Subscribers  connected 
to  PSNs  and  operating  In  AUTOOIN  II  modes  will  have  access  to 
Narrative/Record  Message  Transfer  service  only  when  an  I-S/A  AMPE 
subscriber  Is  the  addressee.  Otherwise  their  traffic  will  be  handled 
by  the  PSN  network  as  ADP  transactions.  In-transit  and  history 
message  storage  will  be  provided  by  the  I-S/A  AMPEs  and  I-S/A 
AMPE(E)s.  PSNs  provide  only  In-transit  packet  storage. 

(2)  Na rrat 1 ve/Record  Message  File  Retrieval.  Narrative/ 
record  messages  passing  through  I-S/A  AMPEs  and  I-S/A  AMPE(E)s  will 
be  stored  for  a prescribed  period  of  time.  Other  data  such  as 
standard  forms  may  also  be  stored  In  these  elements  by  a user  on 
request  for  later  recall.  The  I-S/A  AMPE(E)  will  also  provide  a 
storage  and  retrieval  service  for  other  users  (l.e.,  PSN-connected 
subscribers)  who  can  store  and  retrieve  data  by  addressing  the  I-S/A 
AMPE(E). 


(3)  ADP  Transaction  Transfer.  The  PSNs  are  designed  to 
handle  ADP  transactions  for  hosts  and  subscriber  terminals.  The 
service  will  also  be  provided  to  I-S/A  AMPE  and  I-S/A  AMPE(E) 
subscribers  via  the  TAG  function  provided  In  those  elements.  All  ADP 
transactions  generated  by  I-S/A  AMPE  and  I-S/A  AKPE(E)  subscribers 
will  be  forwarded  to  a PSN  for  routing. 

(4)  Privacy  Service.  This  service  will  be  available  to 
I-S/A  AMPE  or  I-S/A  AMPE(E)  connected  subscribers.  It  Is  a 
reduction  In  the  normal  narrative/ record  transfer  service  only  In 
that  the  I-S/A  AMPE  and  I-S/A  AMPE(E)  will  not  retain  storage  of 
messages  for  retrieval  or  history.  Journals  will  be  maintained. 


(5)  InfonMl  Message  Exchange.  This  service  Is  available  to 
PSN*  NS/A  AMPE,  and  NS/A  AMPE(E)  connected  subscrlbars.  This  typa 
of  message  bypassas  the  normal  narratlva/racord  fonaat  verification 
and  controls  In  tha  NS/A  AMPEs  and  NS/A  AMPE(E)s.  Tha  sanrlca  Is 
Inharantly  avallabla  between  PSN '-connected  subscrlbars  slnca  tha  PSNs 
do  not  procass  aassaga  foraats. 

(6)  Mailbox  Service.  Regardless  of  sourca.  Mailbox  aossagas 
will  bn  routad  to  an  NS/A  AMPE(E)  which  will  aaka  tha  approprlata 
distribution  of  tha  aassagas  to  aallboxas  locatad  In  othar  NS/A 
AMPC(E)s  throughout  tha  network.  Subscrlbars  connactad  to  an  NS/A 
AttPE(E)  will  hava  thalr  aallbox  traffic  distributed  by  tha  connactad 
NS/A  AMPE(E).  For  taralnals  connactad  to  an  NS/A  AMPE,  tha  I-S/A 

r*Z  will  recognize  nallbox  transactions  and  forward  than  to  a 
- ignated  NS/A  AMPE(E)  for  distribution  to  mailboxes.  Subscrlbars 
jnnected  to  PSNs  must  address  thalr  mailbox  traffic  to  an  NS/A 
MPE(E)  since  tha  PSN  will  not  hava  tha  capability  of  distinguishing 
.tween  mailbox  transactions  and  othar  transactions.  Tha  NS/A 
nMPE(E)  will  store  mailbox  traffic  for  designated  users  and  will: 

o Respond  to  Inquiries  from  tha  users  requesting  Information 
concerning  thalr  mailbox  (e.g.,  number  of  massages  In  tha 
mailbox  and  thalr  time  of  arrival) 

o Control  access  to  mailboxes 

o Deliver  mailbox  massages  to  tha  users  upon  request 

o Remove  aallbox  traffic  from  tha  system*  after  notifying  the 
originator  and  addressee*  If  not  retrieved  within  a specific 
time. 

Mailbox  service  Is  an  augmentation  to  tha  Informal  massage  exchange 
service. 

<7)  Data  Teleconferencing.  In  the  preferred  architecture, 
an  NS/A  AMPE(E)  controls  tha  conference,  stores  conference 
transactions  and  responds  to  requests  for  conference  data  or  status 
Information  from  tha  members.  Tha  data  telaconference  service  Is 
avallabl#  to  subscrlbars  connected  to  PSNs*  NS/A  AMPEs  and  NS/A 
AMPE(£)s.  NS/A  AMPEs  will  recognize  teleconference  transactions  and 
forward  them  to  an  NS/A  AMPE(E)  for  processing,  but  subscribers 
connected  to  PSNs  will  hava  to  address  tha  transactions  to  an  NS/A 
AMPE(E).  A user  may  establish  a conference  by  sending  a request 
Including  Identification  of  tha  desired  members  to  an  NS/A  AMPE(E). 


The  NS/A  AMPE(E)  will  notify  the  members  and  provide  them  with  the 
addressing  Information  necessary  to  address  the  conference  or 
retrieve  conference  data  or  status  Information.  All  conference 
transactions  will  flow  through  the  I-S/A  ANPE(E)  controlling  the 
conference.  When  members  are  signed  onto  a conference,  they  will 
automatically  receive  all  transactions  addressed  to  the  conference  or 
to  them  Individually.  The  NS/A  AMPE(E)  will  store  a transcript  of 
the  conference  so  that  members  signing  on  to  the  conference  may 
retrieve  prior  conference  entries. 

f.  Traffic  Flow.  The  flow  of  traffic  through  the  network  In  the 
preferred  architecture  Is  described  In  the  following  subparagraphs 
for  different  types  of  traffic  originated  by  subscribers  connected  to 
each  of  the  major  network  elements.  There  are  two  basic  types  of 
subscribers  expected  In  the  M1d*-Term  IAS.  The  first  type  of 
subscriber  may  have  terminal  equipment  (Including  AMPE)  which  will 
support  only  AUTOOIN  I operation  or  may  not  have  sufficient  need  for 
new  services  to  Implement  the  necessary  changes  in  operational 
procedures.  The  second  typ«  of  subscriber  expected  In  the  Mid-Term 
IAS  Is  an  ADP,  or  AUTOOIN  INtype,  subscriber.  In  the  following 
discussion  these  subscribers  are  referred  to  as  AUTOOIN  I - type  and 
AUTOOIN  II  - type  respectively.  Either  type  may  be  connected  to  an 
NS/A  AMPE(E).  I-S/A  AMPE  or  PSN. 

(I)  I-S/A  AHPE(E)  Connected  Subscribers.  Traffic  submitted 
to  the  I-S/A  AMPE(E)  from  AUTOOIN  I - type  subscribers  will  be 
addressed  with  Plain  Language  Addresses  (PLAs)  or  Routing  Indicators 
(RIs)  and  may  be  In  any  one  of  the  AUTOOIN  I formats  (JANAP  128, 
ACP-126/127,  001-103,  DO  173).  This  traffic  will  be  automatically 
transferred  to  the  store-and- forward  message  processing  portion  of 
the  I-S/A  AMPE(E)  where  AMPE  and  AUTOOIN  I type  functions  are 
performed  (see  2, a, (2)  - Figure  9).  Local  distribution  to 
directly  connected  subscribers  (Including  al 1 led/tactical ) will  be 
made  directly  from  the  I-S/A  AMPE(E)  as  required,  and  network  Logical 
Addresses  (LA)  will  be  determined  for  remote  addressees.  The  I-S/A 
AMPE(E)  will  segment  and  forward  the  messages,  through  the  PSN 
network,  to  the  destination  NS/A  AMPE(E),  I-S/A  AMPE  or  PSN  - 
connected  subscriber.  As  part  of  the  Virtual  Message  Protocol,  the 
originating  I-S/A  AMPE(E)  will  provide  Information  to  the  destination 
I-S/A  AMPE  or  I-S/A  AMPE(E)  concerning  the  origination  code  and  format 
to  allow  necessary  conversions  to  be  made  for  the  destination 
subscriber  and  provide  for  message  servicing  actions.  PSN  » 
connected  subscribers  that  are  cut-though  to  the  originating  I-S/A 
AMPE(E)  will  be  treated  as  local  subscribers  by  that  I-S/A  AMPE(E). 


Transition  logs,  histories  and  retrieval  storage  will  be  maintained 
at  the  I-S/A  AMPE(£)  and  I— S/A  AMPE  unless  the  originating  subscriber 
Is  designated/authorized  for  limited  privacy  service.  In  which  case  no 
permanent  storage  of  the  message  Is  maintained. 

AUTOOIN  II  - type  subscribers  connected  to  an  I-S/A 
AMPE(E)  may  enter  traffic  in  any  one  of  the  AUTOOIN  I formats  or  In 
AUTOOIN  II  format.  The  traffic  entered  In  AUTOOIN  I format  will  be 
addressed  using  PEA  or  RI.  It  will  be  forwarded  to  the 
store-and- forward  portions  of  the  I-S/A  AMPE(E)  and  handled  as 
described  above. 


Traffic  entered  In  AUTOOIN  II  format  will  provide 
segment  leader  Information,  Including  network  LA  with  each 
transaction,  and  the  text  will  be  free  format,  l.e.,  the  message 
format  may  be  one  of  the  AUTOOIN  I formats  or  other  user-to-user 
format.  For  AOP  transaction  transfers  requiring  no  additional 
processing,  the  I-S/A  AHPE(E)  segments  the  traffic  and  forwards  it  to 
a PSN  for  routing.  No  local  routing  Is  done  for  this  type  of  traffic 
by  the  I-S/A  AHPE(E). 

Transactions  requiring  processing  by  the  I-S/A  AMPE(E) 
for  Informal  Message  Exchange,  Mailbox  Service  or  Oata 
Teleconferencing  will  be  identified  by  leader  Information.  Mailoox 
transactions  Include  posting  of  messages  and  retrieval  of  mall  or 
status  Information,  Teleconference  transactions  Include  establishing 
a conference  or  requesting  conference  status/transactions.  Informal 
message  exchange  transactions,  other  than  mailbox  and 
teleconferencing,  can  be  forwarded  to  a PSN  without  further 
processing  by  the  I-S/A  AMPE(E),  but  may  require  special  handling 
such  as  multiple  addressing. 

(2)  I-S/A  AMPE  Connected  Subscribers.  Traffic  entered  to  an 
I-S/A  AMPE  from  AUTOOIN  I - type  subscribers  will  be  formatted  in  an 
AUTOOIN  I format  and  addressed  with  RI  or  PLA.  It  will  be 
automatically  transferred  to  the  store-and-forward  portion  of  the 
I-S/A  AMPE  where  AMPE  and  AUTOOIN  I - type  functions  are  performed. 

If  the  message  requires  services  not  provided  by  the  I-S/A  AMPE,  it 
will  be  forwarded  to  a directly  connected  I-S/A  AMPE(E)  or  through 
the  PSN  network  to  a remote  I-S/A  AMPE(E).  If  k>  I-S/A  AMPE(E) 
services  are  required  the  message  will  be  distributed  locally  as 
necessary  and/or  forwarded  through  the  PSN  network  to  the  destination 
I-S/A  AMPE(E),  I-S/A  AMPE  or  PSN-connected  subscriber.  The  YMP 
protocol  used  by  the  I-S/A  AMPE  for  exchange  of  messages  with  other 
I-S/A  AMPEs  and  I-S/A  AMPEIEls  will  allow  the  transfer  of  Information 
concerning  the  origin  of  the  message  and  processing  required. 


Traffic  entered  by  AUTOOIN  II  - type  subscribers  will  be 
In  AUTOOIN  I or  AUTOOIN  II  fonaat.  The  AUTOOIN  I format  messages 
will  be  transferred  to  the  store-and- forward  portion  of  the  I-S/A 
AMPE  and  processed  as  described  above.  For  AUTOOIN  II  format 
transactions,  the  I-S/A  AMPE  will  perform  PSN  TAC  equivalent 

• functions,  segment  the  data,  and  forward  It  to  the  PSN.  If  the  I-S/A 
AMPE  Is  not  directly  connected  to  a PSN,  this  traffic  Is  forwarded  to 
a directly  connected  I-S/A  AMPE(E).  At  the  present  time,  procedures 
for  separating  traffic  intended  for  I-S/A  AMPE(E)  processing  versus 
relay  to  the  PSN  by  the  I-S/A  AMPE(E)  have  not  been  defined. 

However,  this  could  be  accomplished  through  recognition  of  LA  by  the 

_ I-S/A  AMPE(E)  as  part  of  a SIP-to-SIP  transfer,  by  transmission  of 

* the  two  traffic  types  from  the  I>*S/A  AMPE  via  two  separate  logical  or 
physical  channels. 

The  I-S/A  AMPE  will  recognize,  via  segment  leader 
designators,  transactions  that  require  services  provided  only  by  an 
I*S/A  AMPE(E),  such  as  mailbox  or  teleconferencing,  and  will  forward 
the  transaction  to  an  I-S/A  AMPE(E)  by  inserting  a segment  leader 
with  the  I-S/A  AMPE(E)  LA.  Otherwise,  segments  will  be  relayed 
through  the  I-S/A  AMPE(E)  containing  only  the  destination  LA. 

(3)  PSN-Connected  Subscribers.  AUTOOIN  I - type  subscribers 
connected  to  PSNs  will  be  automatically  cut-through  to  a designated 
O I-S/A  AMPE(E).  All  traffic  generated  by  these  subscribers  will  be 

automatically  routed  to  the  I-S/A  AMPE(E)  which  will  process  the 
traffic  as  If  It  came  from  a local  AUTOOIN  I -type  subscriber. 

Traffic  generated  by  AUTOOIN  II  - type  subscribers 
connected  to  PSNs  must  be  In  AUTOOIN  II  format  with  segment  leader 
C information  provided.  Transactions  which  require  I-S/A  AHPE(E) 

services  must  be  addressed  to  an  I-S/A  AMPE(E)  since  the  PSNs  will 
not  recognize  the  r.eed  for  such  services. 

g.  Security.  The  Security  Subsystem  for  the  preferred  IAS 
Mid-Term  Architecture  must  provide  the  capability  to  support  both 
C end-to-end  encrypted  (E3)  users  and  link  encrypted  users.  It  is 

expected  that  this  mix  of  E3  and  non-E3  users  will  persist  throughout 
the  mid-term  and  well  Into  the  far-term. 

The  non-E3  users  will  be  provided  security  service  through 
the  use  of  conventional  link  encryption  techniques  such  as  those 
£ employed  In  AUTOOIN  I and  AUTOOIN  II.  Non-E3  users  will  be  supported 

by  a variety  of  link  encryption  devices  such  as  the  KG-13,  KG-34,  and 
KG-84.  Non-E3  users  will  be  afforded  end-to-end  security  In  the 
Mid-Term  IAS  through  a combination  of  link  encryption  and  security 
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kernels,  or  other  certified  techniques,  used  In  the  IAS  network 
elements.  These  users  will  also  be  provided  with  traffic  flow 
security  (TFS)  protection  through  the  Inherent  TFS  features  of  the 
link  key  generators  employed  for  encryption/ decryption.  This  class 
of  user,  however,  will  not  be  provided  with  automatic  access  control, 
user  authentication,  or  on-line  key  distribution. 

The  E3  users  will  be  provided  service  through  the  application 
of  BLACKER  hardware  and  supporting  security  software  Integrated  Into 
the  various  system  elements  of  the  IAS.  The  allocation  of  BLACKER 
components  to  the  IAS  elements  Is  discussed  In  a separate  classified 
Appendix.  E3  subscribers  must  be  capable  of  accessing  network 
services  (e.g.,  message  processing,  mailbox,  teleconferencing)  as 
well  as  other  E3  subscribers.  Furthermore , E3  subscribers  and  non-E3 
subscribers  must  be  able  to  access  each  other.  The  E3  operational 
scenarios  include  three  generic  types  of  connections: 

o Terminal -to- terminal 

o Terminal -to-host 

f 

o Host-to-host 

Descriptions  of  several  operational  scenarios  are  presented  In 
Appendix  E. 

h.  System  Control.  The  Mid-Term  Architecture  will  make  use  of 
available  and  planned  DCS  system  control  capabilities  and  resources. 
The  preferred  architecture  does  not  require  changes  to  the  system 
control  functions  of  the  AUTODIN  II  PSNs  and  Network  Control  Center 
( NCC ) . Introduction  of  the  I-S/A  AMPE  and  I -S/A  AMPE(E)  will  allow 
monitoring,  control,  reporting  and  restoral  functions  to  be  performed 
at  a lower  level  In  the  network  and  thus,  improvements  should  be 
realized  In  efficiency  and  reaction  time. 

As  major  message  processing  and  subscriber  terminating 
elements,  the  I*-S/A  AMPE  and  I-S/A  AMPE(E)  must  perform  most  of  the 
system  control  functions  performed  by  the  ASC  and  some  of  those 
performed  by  the  PSN.  The  Automated  Technical  Control  ( ATEC ) 
Improvement  will  be  completed  prior  to  Implementation  of  these 
elements,  and  they  should  be  designed  to  take  advantage  of  the  ATEC 
Station  level  capabilities,  as  appropriate.  Table  V lists  the 
major  system  control  functions  required  In  the  I-S/A  AMPE  and  I-S/A 
AMPE(E).  Although  all  of  the  functions  listed  apply  to  both 
elements,  the  scope  of  the  functions  will  be  somewhat  different.  For 
example,  the  I-S/m  AMPE(E)  will  collect  reports  from  a number  of 
I-S/A  AMPEs  and  generate  a consolidated  report  to  the  NCC  or  other 
DCS  control  centers. 


TAKE  V.  I -S/A  *l»t,  I-S/A  ANPE(E)  SYSTEM  CONTROL  FUNCTIONS 


network  Control  Functions 

Patch  and  Tost  Facility 

Intersystem  Interface 

Status  Monltorlng/Performance  Assessment 
(Terminals,  trunks,  access  lines) 

Internal  Control 

- Res tart/ recovery 
Program/table  reload 

- Diagnostics 

• Hardware/ software  monitoring 
Statistics  Generation 

(Circuit  Outage.  Circuit  Performance,  etc.) 

Reporting 

Circuit  Restoral /Reconfiguration 

Traffic  Control  Functions 
Message  Routing 

- Primary 

• A1  temate 
Message  Distribution 
Traffic  Flow  Control 

Traffic  Accountability  and  Integrity 

Status  Monitoring/Performance  Assessment 
(Traffic  conditions,  backlogs,  resource  utllitatinn) 
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TABLE  V.  I-S/A  AMPE,  NS/A  AMPE(E)  SYSTEM  CONTROL  FUNCTIONS  (Continue) 


Statistics  Separation 


- Billing  Data 

- Traffic  Voluaes,  Processing  tlaes.  etc 
Service  Message  Generation 

Reporting 


Sine*  these  elements  will  tenslnete  the  majority  of 
subscribers  In  the  systam  It  will  be  necessery  for  the*  to  collect 
end  report  subscriber  traffic  statistics  for  billing  purposes.  They 
will  also  record  the  status  Information  and  statistics  necessary  to 
support  system  engineering  and  traffic  management.  The  equivalent  to 
55-1  reports.  ASC  System  Status  reports  and  history  Information 
(header  extracts)  will  be  necessary.  The  new  elements  should  provide 
the  capability  for  further  automation  of  the  collection  and  reporting 
of  this  Information.  Additionally,  the  performance  monitoring 
Information  provided  by  the  PSN  TAC  function  must  be  collected  from 
the  l-S/A  AMPE  and  I-S/A  ANPE(E).  With  the  Implementation  of  the  new 
elements,  consideration  should  be  given  to  additional  automation  such 
as  on-line  diagnostics  and  downline  program/table  loading,  to 
facilitate  control  and  assistance  from  the  NCC  or  other  DCS 
operations  canters. 

1.  Tactical  Interfaces.  By  TRI-TAC  Program  definition,  tactical 
systems  will  be  Interoperable  with  current  and  planned  DCS 
networks.  The  general  mode  of  circuit  verification  and  system 
control  between  the  OCS  and  tactical  systems  will  Initially  be 
manual,  with  a goal  of  Increasing  automation  between  control 
•laments  on  a cost-effective  basis  (via  ATEC).  A secure  record 
orderwlre  will  be  required  at  the  OCS/tactlcal  nodal  element 
Interface,  and  probably  at  the  OCS  Sector  to  tactical 
Communications  System  Control  Element  (CSCE)  and  DCS  Theater  to 
tactical  Communications  System  Planning  Element  (CSPE)  as  well. 

Those  oroerwlre  cl cults  should  be  Interconnected  with  OCS  and 
tactical  system  orderwlres  as  necessary.  In  addition,  processor-to- 
processor  links  should  be  provideo  between  system  control  elements 
to  accoaendate  the  Interchange  of  data  base  updates.  The  IAS 
elements  are  expected  to  Interface  through  the  tactical  Communi- 
cations Nodal  Control  Element  (CNCE)  to  the  tactical  switches 
(TVC-JB)  as  shown  In  Figure  17. 

Selection  of  suitable  formats  and  protocols  for  exchange  of 
Information  across  the  OCS/Tactlcal  Interface  is  highly  dependent 
upon  operational  procedures  yet  to  be  developed,  particularly  with 
regard  to  the  Joint  *kil tl channel  Trunking  and  Switching  Systems 
(JHTSS).  Procedures  also  affect  OCS  and  tactical  system  control 
software  because  anything  short  of  compatible  system  control  data 
bases  and  compatible  system  control  processing  algorithms  will 
require  translation  on  every  Interchange  of  system  control 
Information  across  the  boundary.  While  a protocol  has  been 
recoaBondee  for  use  with  the  Tactical  Communication  Control 
Facility  (Reference  F),  it  may  not  provide  the  most  effective 
aethod  of  passing  status  messages,  directives,  and  control  data 
across  the  OCS/Tactlcal  Interface.  Consideration  should,  therefore, 
be  given  to  the  use  of  AUT001N  procedures  and  protocols,  or 
development  of  a special  protocol  as  the  means  of  providing  system 


Figure  17.  IAS/TR1-TAC  Element  Interfaces 


control  Information  flow  (both  near  rail -tine  and  longer  range) 
across  the  Interface. 

j.  Survivability.  As  stated  previously,  enhanced  survivability 
Is  a major  architectural  objective.  Toward  this  end  a number  of 
decisions  were  made;  avoid  allocating  critical  functions  to  an 
element  that  Is  In  short  supply  such  as  the  CSF,  and  avoid 
bottlenecks/choke  points  such  as  home  nodes  or  reaching  the  backbone 
only  via  another  element.  The  Mid-Term  IAS  provides  for  a backbone 
of  PSNs  and  packet  trunks  whose  sole  function  Is  the  efficient 
movement  of  bits  In  bulk.  All  "services*  are  provided  In  the  access 
area  close  to  the  subscribers.  The  two  major  elements  In  the  access 
area,  the  I-S/A  AMPE  and  the  I-S/A  AMPE(E),  differ  from  one  another 
In  the  applications  software  and  amount  of  hardware,  such  that 
conversion  from  one  to  the  other  Is  accomplished  by  adding  or 
subtracting  software/hardware  In  modules.  Both  have  a Mode  VI 
Interface  to  the  backbone  and  the  necessary  protocols  so  that  they 
can  readily  Intercommunicate  via  the  backbone.  Both  terminate  packet 
network  and  message  network  subscribers. 

k.  Summery.  As  evidenced  by  the  preceding  discussions,  the 
perferred  architecture  Is  well  defined  and  represents  a viable 
approach  to  the  Mid-Term  IAS.  This  architecture  Is  fully  responsive 
to  the  ASD(C3I)  tasking  and  the  architectural  objectives  for  the 
Mid-Term  IAS  established  by  OCA.  The  following  paragraphs  describe 
the  two  alternative  archl tectures  considered  for  the  Mid-Tern  IAS  In 
terms  of  their  significant  differences  from  the  preferred 
architecture.  The  final  paragraph  In  this  section  will  compare  the 
three  alternatives  and  provide  the  principal  reason  for  selecting  the 
preferred  architecture. 

3.  description  of  first  alternate  architecture 

Architecture  III  was  ranked  second  In  preference  as  a result  of 
the  evaluation  of  the  candidate  architectures.  This  architecture  Is 
described  In  the  following  paragraphs  in  terms  of  Its  differences 
from  the  preferred  architecture.  Architecture  II.  Figure  18 
shews  the  major  elements  of  Architecture  III  and  their  generic 
Interconnections. 


a.  Elements.  The  major  elements  which  comprise  Architecture  III 

IT*  25  l-S/A  AMPS,  I-S/A  AMPE(E),  CSF.  and  subscriber  terminals. 
The  FSN,  I-S/A  AMPE.  and  subscriber  terminals  are  the  same  elements 
described  for  Architecture  II.  The  I-S/A  AMPE(E)  Is  the  same  as 
described  for  Architecture  II  except  that  It  does  not  provide  the  new 


Figure  18.  Architecture  III  Configuration 


IAS  network  services.  As  In  Architecture  II,  the  I>S/A  AMPE(E) 
performs  the  AMPE  functions  and  ASC  terminal  support  and  network 
functions,  and  Is  a modular  enhancement  to  the  NS/A  AMPE.  A 
Centralized  Service  Facility  (CSF)  Is  provided  In  Architecture  III  to 
perform  the  new  functions  Identified  for  the  m1d*-tern  and  Is  also  the 
primary  expansion  element  to  assume  new  functions  as  new  requirements 
are  Identified.  The  CSF  connects  to  one  or  more  PSNs  as  a host 
computer.  Although  It  provides  user  service  via  network  access.  It 
does  not  terminate  subscribers. 

b.  Configuration/Connectivity.  Connectivity  options  for  all 
common  elements  are  the  same  for  Architecture  III  and  Architecture 
II.  The  CSF  connects  only  to  PSNs  and  uses  an  AUTOOIN  II,  Mode  VI, 
Binary  Sejpent  Leader  host  Interface.  Gateways  to  external  packet 
networks  will  be  Implemented  In  the  CSF  In  Architecture  III.  New 
narrative/record  Interfaces  to  existing  tactical  elements  such  as  the 
TYC-39  can  be  Implemented  In  the  NS/A  AMPE  or  NS/A  AMPE(E). 

c.  Protocols.  As  for  Architecture  II,  Architecture  III  requires 
no  new  protocols  to  be  Implemented  In  existing  elements.  Link  level 
and  network  level  protocols  are  the  same  as  for  the  corresponding 
elements  of  Architecture  II.  The  CSF  will  coMunlcate  through  the 
PSN  network  with  other  host  computers,  NS/A  AMPEs,  NS/A  AMPE(E)s 
and  terminals  as  a host  computer,  and  will  therefore  Implement  SIP, 
TCP  and  THP  protocols. 

d.  Functional  Allocations.  The  availability  of  services  to  the 
various  types  of  subscribers  Is  the  same  In  Architecture  III  as  In 
Architecture  II,  except  that  some  of  the  services  are  obtained  from 
the  CSF  Instead  of  the  NS/A  AMPE(E). 

The  procedure  for  allocation  of  functions  In  Arcnltecture  III 
was  to  allocate  those  functions  associated  with  new  IAS  services  to 
the  CSF  and  all  ASC  functions  to  the  NS/A  AMPE(E),  and  then  examine 
the  functions  one  by  one  to  determine  whether  better  performance  or 
cost  savings  could  be  realized  by  moving  any  of  the  functions  from 
one  element  to  the  other.  Through  this  approach.  It  was  determined 
that  the  mailbox  functions  could  be  more  effectively  performed  by  the 
NS/A  AMPE(E),  primarily  because  the  NS/A  AMPE(E)  must  perform 
similar  functions  for  the  narrative/record  message  store-end* forward 
and  retrieval  services,  and  the  mailbox  service  Is  more  efficiently 
provided  near  the  subscribers.  These  functions  were  therefore 
reallocated  to  the  NS/A  AMPE(E)  and  all  other  functions  remained  as 
originally  allocated.  The  CSF  In  Architecture  III  must  perform  those 
functions  associated  with  the  data  teleconferencing  service  and  E3 
functions. 


These  functions  are  summarized  In  Table  VI.  Additional  functions 
will  probably  be  required  of  the  CSF  as  a result  of  the 
Implementation  of  gateways  to  other  networks.  The  functional 
allocations  for  all  other  elements  are  the  same  as  for  Architecture 
II. 


e.  Operational  Characteristics.  The  differences  In  operational 
characteristics  of  Architecture  III  and  Architecture  II  are  described 
In  the  following  paragraphs  In  terms  of  traffic  flow,  security  and 
system  control. 

• 

(1)  Traffic  Flow.  There  Is  one  major  difference  In  the 
traffic  flow  of  Architectures  II  and  III.  That  difference  Is  created 
by  the  splitting  of  services  between  the  CSF  and  the  I«S/A  AMPE(E)  In 
Architecture  III.  In  Architecture  II,  all  traffic  entering  an  NS/A 
AHPE  requiring  services  not  provided  by  the  NS/A  AMPE  Is  routed  to 
an  NS/A  AMPE(E).  In  Architecture  III  this  traffic  may  require 
routing  to  either  an  NS/A  AMPE(E)  or  a CSF.  depending  on  the 
specific  service  required.  The  NS/A  AMPE  will  therefore  have  to 
make  the  routing  decisions.  Likewise,  traffic  generated  by 

PSh ‘-connected  subscribers  may  require  routing  to  either  a CSF  or  an 
NS/A  AMPE(E)  for  services.  In  this  case,  the  subscriber  will  have 
to  make  the  decision  and  address  the  transactions  accordingly.  NS/A 
AMPC(E)s  will  also  have  to  route  some  of  the  traffic  generated  by 
their  subscribers  to  a CSF  for  additional  services. 

(2)  Security.  Security  for  non-E3  users  Is  provided  In 
Architecture  III  exactly  as  It  Is  In  Architecture  II.  Security  for 
E3  users  Is  provided  In  the  same  manner  as  Architecture  II  except 
that  the  BLACKER  elements  may  be  located  at  different  places  In  the 
network.  Tradeoffs  for  location  of  these  elements  are  discussed  In 
Appendix  E. 


(3)  System  Control.  System  control  considerations  are 
essentially  the  same  for  Architecture  III  as  for  Architecture  Ii 
except  that  an  additional  requirement  will  exist  for  control  of  tne 
CSFs  and  performance  of  system  control  functions  by  the  CSFs.  The 
NS/A  AMPE(E)  and  NS/A  AMPE  will  be  required  to  perform  the  same 
functions  as  In  Architecture  II.  The  CSF  functions  In  this 
architecture  consist  mainly  of  Internal  status  monitoring  and 
reporting  and  statistics  generation.  The  major  system  control 
functions  envisioned  for  the  CSF  are  listed  In  Table  VII. 


TABLE  VI.  CSF  FUNCTIONS.  ARCHITECTURE  III 


Message  Switching 

- Precedence  Queuing/Pre-emption 

- Routing  (Single  Address) 

- Routing  (Multiple  Address  - single  and  multiple  transmissions). 

Packet  Switching 

- Leader  Validation 

- Precedence  Queuing 

- Routing  (For  Conferencing) 

Protocols 

- Host- to- Mode 

- Host-tO-Host 

- Node  VI  Link 

Message  Storage  and  Retrieval 

- Store  On-line  for  Retrieval 

- Net sage/FI le  Access  Control 

• Retrieval  (By  IV,  Addresser.  Tine  of  Receipt,  Code  Word) 

System  Management  and  Control 

- Journal Ing/Logglng 

• Message  Recovery 

- Services  Message  Generation 

• Flow  Control 

- Statistics  Generation 

• Billing 

• Status  Monitoring 
Security 

- Encryption/Decryption 

• Automatic  Key  Variable  Distribution 

• Access  Control 

- User  Authentication 

- Security  Trace  and  Audit 

• Data  Authentication 

- Traffic  Flow  Security 


TABLE  VII.  CSF  SYSTEM  CONTROL  FUNCTIONS,  ARCHITECTURE  III 


Network  Control  Functions 
Internal  Control 

- Restart/recovery 

• Program/ table  reload 

• Diagnostics 

- Hardware/ software  monitoring 
. Reporting 

Traffic  Control  Functions 
. Message  Routing 
. Traffic  Flow  Control 

Traffic  Accountability  and  Integrity 
Status  Nonltorlng/PerfOrmance  Assessment 
(Traffic  condition,  backlogs,  resource  utilization) 
Statistics  Generation 

- Billing 

- Traffic  Volumes,  Processing  Times,  etc. 

. Service  Message  Generation 

. Reporting 


4.  DESCRIPTION  OF  SECONO  ALTERNATE  ARCHITECTURE 


Architecture  I was  ranked  third  In  preference  as  a result  of 
evaluation  of  the  candidate  architectures.  This  architecture  Is 
described  below  In  'terns  of  Its  differences  from  the  preferred 
architecture.  Architecture  II.  Figure  19  shows  the  major 
elements  of  Architecture  I and  their  generic  Interconnections. 


a.  Elements.  The  major  elements  of  Architecture  I are  the  PSN. 
I-S/A  AMPE,  CSF  and  subscriber  terminals.  This  alternative  does  not 
Include  an  I-S/A  AMPE(E).  The  PSN.  I-S/A  AMPE  and  subscriber 
terminals  used  In  Architecture  I are  the  same  elements  as  those 
described  for  Architecture  II.  The  CSF  In  Architecture  I provides 
ASC  subscriber  support  functions  for  subscribers  connected  to  PSNs 
and  provides  ASC  network  functions  and  new  IAS  functions  for  all 
subscribers  In  the  network.  The  CSF  Interfaces  to  one  or  more  PSNs 
as  a host  computer.  It  does  not  terminate  subscribers. 

b.  Configuration/Connectivity.  Connection  options  for 
Architecture  I are  essentially  the  same  as  Architecture  II  for  the 
cohmwi  elements.  However.  AUT00I.N  I terminals  connected  to  PSNs  will 
be  cut-through  to  a CSF  Instead  of  an  I-S/A  AMPE(E).  The  CSF 
connects  only  to  PSNs  and  uses  an  AUTOOIN  II.  Mode  VI.  Binary  Segment 
Leader  host  Interface.  Gateways  to  either  packet  networks  or 
narrative/ record  1nUrf»c»s  to  existing  tactical  elements  such  as  the 
TYC-39  will  be  Implemented  In  the  I-S/A  AMPE. 

c.  Protocols.  Architecture  I requires  no  new  protocols  to  be 
Implemented  In  existing  elements.  Link  level  and  network  level 
protocols  are  the  same  as  for  corresponding  elements  In  Architecture 
II.  Since  the  CSF  Interoperates  through  the  PSN  network  with  other 
elements.  It  will  Implement  SIP,  TCP  and  THP  protocols.  It  will  also 
perform  narrative/record  services  and  must  therefore  Implement  VHP. 

d.  Functional  Allocation.  The  availability  of  services  for  the 
various  types  of  subscribers  Is  the  same  in  Architecture  I as  In 
Architecture  II,  except  that  all  services  are  obtained  from  the  CSF 
Instead  of  the  I-S/A  AMP£(E).  For  this  architecture  all  ASC  services 
as  well  as  new  IAS  services  were  allocated  to  the  CSF,  since  there  Is 
no  I-S/A  AMPE(E)  In  the  architecture.  E3  functions  are  also 
allocated  to  the  CSF  although  they  could  optionally  be  allocated  to 
other  elements  (see  Appendix  E).  Table  VIII  summarizes  the 
functions  required  of  the  CSF  to  provide  these  services.  The 
functions  performed  by  the  other  elements  are  the  same  as  for 
Architecture  II. 


TABLE  VIII.  CSF  FUNCTIONS,  ARCHITECTURE  I 


MESSAGE  SWITCHING 
Header  Validation 
Precedence  Queuing/Pre-emption 
Routing  (Single  Address) 

Alternate  Routing  (Remote) 

Multiple/Collective:  Multiple  Transmission/Line 

Single  Transmission/Line 
Routing  Line  Segregation 


TRC/SPECAT  Processing 
MCB  Functions 


PACKET  SWITCHING 
Leader  Validation 
Routing 

Precedence  Queuing 


FORMAT  PROCESSING 
JANAP  - 128 
ACP  - 127 
ACP  - 126 
001  - 100 
001  - 103 
DO  - 173 

CONVERSION  FUNCTIONS 
Message  Format:  JANAP  128/ACP  127 

DO  173/ JANAP  128,127 
Media  Format  (Card,  Type,  Etc.) 
PLA.RI/Loglcal  Address 
PLA/RI 
Code 


PROTOCOLS 
Host-to-Node 
Host-to-Host 
Llnk-AUTOOIN  I,  Mode  VI 


MESSAGE/FILE  STORAGE  i RETRIEVAL 
Store  Off-Line  For  Retrieval 
Store  On-Line  For  Retrieval 


TABLE  VIII.  CSF  FUNCTIONS,  ARCHITECTURE  I (Continued) 


Intercept  Storage 
Message/File  Access  Control 
Retrieve  By:  Message  ID 
Addressee 
Time  or  Receipt 
Code  Word 


SYSTEM  MANAGEMENT  & CONTROL 
Journal ing/Logglng 
Message  Recovery  Retrieval 
Service  Message  Generation 
Flow  Control 
Statistics  Generation 
Billing 

Status  Monitoring 
Message  Trace 


SECURITY 

Encryption/Decryption 

Automatic  Key  Variable  Distribution 

Access  Control 

User  Authentication 

S/P/TCC  Validation 

Security  Trace  and  Audit 

Data  Authentication 

Traffic  Flow  Security 
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e.  Operational  Characteristics.  The  differences  in  the 
operational  characteristics  of  Architectures  I and  II,  In  the  areas  of 
traffic  flow,  security,  and  system  control,  are  described  In  the 
following  paragraphs. 

(1)  Traffic  Flow.  The  differences  In  traffic  flow  between 
Archl tectures  I and  II  exist  because  the  CSF  Is  accessed  for  services 
In  Architecture  I that  are  provided  by  the  I-S/A  AMPE(E)  In 
Architecture  II.  PSN  - connected  subscribers  will  receive  all  their 
network  services  from  the  CSF.  Al/TODIN  I - type  subscribers  will  be 
cut-through  the  PSN  to  a CSF,  and  the  CSF  will  provide  them  the  ASC 
subscriber  support  and  network  functions  as  if  they  were  directly 
connected.  AUTODIN  II  type  subscribers  connected  to  a PSN  will 
address  transactions  that  reauire  network  service  to  a CSF.  For 
I-S/A  AMPE  - connected  subscribers,  the  I-S/A  AMPE  will  determine 
whether  transactions  require  a network  service  not  provided  by  the 
I-S/A  AMPE  (as  in  Architecture  II),  and  route  the  transaction  to  a 
CSF. 


(2)  Security.  Security  for  non-E3  users  is  provided  in 
Architecture  I exactly  as  in  Architecture  II.  Security  for  E3  users 
is  provided  In  the  same  manner  as  in  Architecture  II  except  that  the 
BLACKER  elements  may  be  located  at  difference  places  in  the  network. 
Trade-offs  for  location  of  these  elements  are  discussed  in  Appendix 
E. 


(3)  System  Control.  System  control  considerations  for 
Architecture  I differ  from  those  of  Architecture  II  because  of  the 
existence  of  CSFs  and  the  absence  of  I-S/A  AMPE(E)s.  Since  the  CSF 
services  narrative/ record  subscribers.  It  will  be  required  to  perform 
all  the  system  control  functions  of  the  I-S/A  AMPE(E)  of  Architecture 
II  except  for  those  that  deal  with  circuit  management  and  control. 

The  same  functions  apply  to  the  I-S/A  AMPE  in  Architectures,  I and  II. 

5.  COMPARISON  OF  ALTERNATIVES  AND  RECOMMENDATION 

The  evaluation  of  alternative  archl tectures  presented  In  this 
section  Is  based  on  the  results  of  technical  analyses  performed  by 
the  support  contractor  to  the  IASA  project  - the  Conmuni cations  and 
Information  Technology  Division  of  Booz,  Allen  and  Hamilton.  The 
detailed  results  of  all  technical  analyses  performed  are  documented 
in  Appendices  B,C  and  0 to  this  report.  In  order  to  facilitate 
evaluation  of  the  alternative  architectures,  some  of  the  most 
significant  results  of  these  studies  are  summarized  In  the  remainder 
of  this  section. 


a.  Technical  Factors  Comparison.  On  the  basis  of  the  technical 
analyses  performed  as  part  of  the  evaluation  process,  the  relative 
advantages  and  disadvantages  of  each  alternative  were  Identified. 

The  following  subparagraphs  present  the  results  of  the  evaluation 
process  In  each  of  the  four  major  technical  evaluation  criteria. 

(1)  Operational  Effectiveness.  Alternative  Architecture  I 
with  Its  Centralized  Service  Facility  and  direct  connection  of 
subscribers  and  I-S/A  AMPEs  to  PSNs  was  determined  to  provide  the 
best  potential  for  performance  In  this  evaluation  category.  Due  to 
Its  less  complex  structure  and  direct  user  access.  Alternative  I 
could  potentially  provide  a slight  advantage  over  the  other  two 
alternatives  in  the  areas  of  service  delivery  time  and  application  to 
overseas  operating  environments.  However,  It  should  be  remembered 
that  each  of  the  alternative  architectures  Is  capable  of  meeting  the 
functional  performance  requirements  and  the  anticipated  technical 
performance  requirements  of  the  Mid-Term  IAS.  It  should  also  be 
recognized  that  the  preferred  alternative  (Alternative  II)  as  well  as 
the  remaining  alternative  (Alternative  III)  provide  a high  degree  of 
flexibility  In  the  access  area  through  dual  connection  of  the  I-S/A 
AMPE  as  well  as  through  alternative  connections  for  both 
narrative/record  and  computer  data  subscribers.  The  system  design 
for  the  preferred  architecture  can  take  advantage  of  this  flexibility 
to  provide  optimum  service  access  for  most  users.  As  a result  of 
this  system  design  optimization,  the  operational  effecti veness  of  the 
preferred  architecture  will  approach  the  optimum  available 
performance. 

(2)  Flexibility.  As  a result  of  the  evaluation.  It  was 
determined  that  Alternative  Architecture  I Is  potentially  less 
sensitive  to  changes  In  the  day-to-day  network  operation  within  the 
original  system  design  limits  due  to  Its  relatively  flat  structure 
(no  access  area  hierarchy)  and  its  potential  for  load  sharing  of 
processing  within  a single  service  element  (i.e.,  the  CSF).  However, 
Alternatives  II  and  III  were  found  to  be  significantly  more  flexible 
and  less  sensitive  to  major  changes  in  requirements  and  future  growth 
because  of  the  greater  number  of  connection/configuration  options 
available  within  these  architectures.  In  addition.  It  should  be 
noted  that  the  Implementation  of  the  new  IAS  network  elements  can 
potentially  have  as  much  Impact  on  system  flexibility  as  the 
architecture  selected.  For  example.  It  Is  currently  anticipated  that 
the  I-S/A  AMPE  and  the  I-S/A  AMPE(E)  will  be  Implemented  based  on  a 
mul tl -processor  architecture.  This  will  permit  the  high  degree  of 
expandability  required  to  permit  graceful  evolution  of  the  I-S/A  AMPE 
throughout  the  mid-term,  and  protect  against  saturation  of  the  I-S/A 
AMPE  processing  capability. 
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(3)  Survivablllty/Avallablllty/Maintalnablllty.  As  a result 
of  the  evaluation  process.  It  was  determined  that  Alternative  II 
offers  a high  degree  of  hardware/software  commonality  and  therefore 
minimizes  the  avallablllty/malntalnablllty  requirements  of  the 
network.  In  addition.  Alternative  II  offers  Improved  survivability 
through  dual  connection  of  the  I<S/A  AMPEs  and  Increased  Independence 
of  the  NS/A  AMPEs  for  simple  message  transfer  operations. 

(4)  Transition.  Based  on  the  evaluation  process. 

Alternative  II  was  found  to  represent  the  best  architectural  basis 
for  transition  from  the  near-term  to  the  Mid-Term  IAS  network.  In 
addition.  Alternative  II  offers  potentially  the  best  architecture  for 
continued  evolution  through  the  far- term  toward  the  OCS  objectives  of 
both  satellite  broadcast  backbone  utilization  and  Integration  of 
voice  and  data  networks.  In  general.  Alternative  II  represents  the 
least  risk  and  difficulty  for  transition  because  only  a single 
network  service  element  must  be  Implemented  (l.e.,  I-S/A  AMPE(E) ). 

In  addition,  development/ Implementation  risk  Is  further  reduced  by 
the  fact  that  the  I-S/A  AMPE(E)  Is  derived  from  the  currently  planned 
NS/A  AMPE  program.  It  should  be  noted  that  the  risk  assessment 
performed  as  part  of  the  evaluation  was  based  upon  the  overall  IAS 
Implementation  strategy  and  technology  trends  defined  by  OCA  (l.e., 
software  first  development  approach,  common  family  of 
hardware/transportable  software,  multiprocessor  nodal  architecture). 

b.  Cost  Factors,  As  part  of  the  alternative  evaluation 
process,  a comparative  cost  analysis  was  performed.  This  analysis 
Identified  all  major  cost  components  of  the  Mid-Term  IAS  and 
evaluated  those  factors  which  were  found  to  be  dependent  upon 
network  architecture.  The  following  subparagraphs  present  the 
results  of  this  analysis  for  the  three  major  elements  of  cost,  l.e. 
transmission  cost,  network  element  acquisition  cost,  and  network 
element  operation  and  maintenance  cost.  For  more  detailed 
discussion  of  cost  see  Appendix  C. 

(1)  Transmission.  As  part  of  the  technical  analyses 
performed  In  support  of  the  Mid-Term  IASA  definition,  a computer 
model  was  developed  and  exercised  to  project  nodal  and  link  traffic 
flows  as  a function  of  architecture.  This  model  is  described  In  • 
Appendix  B.  The  results  of  this  computer  model  were  used  to 
estimate  the  size  of  trunks  and  access  lines  required  to  support 
each  alternative  architecture.  Trunk  and  access  line  distances 
were  calculated  based  on  currently  defined  PSN  and  AMPE  locations. 
Transmission  facility  lease  costs  were  then  calculated  based  on 
available  common  carrier  bulk  tariffs  for  both  voice  grade  and  wide 
band  circuits.  As  a result  of  this  analysis.  It  was  determined 
that  the  maximum  projected  difference  In  transmission  costs  between 
the  "best"  and  the  "worst"  alternative  architectures 


was  less  than  five  percent  of  the  total  transmission  cost.  Further 
analysis  confirmed  that  this  result  was  not  sensitive  to  changes  In 
either  the  underlying  assumptions  or  network  configuration  parameters 
used  In  the  analysis.  Based  on  this  small  projected  difference, 
there  Is  no  clear  preference  among  the  alternative  architectures. 

(2)  Network  Element  Acquisition  Cost.  The  potential 
acquisition  cost  of  all  major  network  elements  was  estimated  for  each 
alternative  architecture.  As  part  of  this  process,  each  element  was 
defined  In  terms  of  a standard  set  of  hardware  components  (e.g.,  tape 
drives,  memory,  processor,  display  units)  selected  from  typical 
state-of-the-art  communications  processing  systems.  The  network 
elements  and  components  were  then  sized  based  on  the  functional 
capabilities  of  the 'element,  as  well  as  the  traffic  (throughput) 
projections  derived  from  the  computer  model  used  for  transmission 
cost  analysis.  Total  network  element  cost  was  then  calculated  based 
on  hardware  component  cost  estimates  collected  through  vendor  surveys 
and  available  literature. 


Based  on  a typical  network  configuration  for  each 
alternative  In  the  1988  time  frame,  a projected  network  element 
inventory  was  developed  (see  Appendix  C).  This  Inventory  took  Into 
account  both  geographic  and  survivability  considerations  In  order 
to  determine  a probable  minimum  number  of  each  type  of  element 
required  for  each  alternative  architecture.  Based  on  the  projected 
Inventory  and  cost  per  element,  system  acquisition  cost  for  the 
network  elements  was  computed.  The  results  of  this  analysis  are 
summarized  In  Table  IX.  Cost  estimates  contained  in  this  table 
represent  the  projected  acquisition  costs  for  network  elements 
based  on  commercial  hardware  suitable  to  a fixed  plant  environment 
and  do  not  Include  the  cost  of  spare  parts,  documentation  or  other 
support  costs.  In  addition,  these  costs  do  not  Include  any 
amortization  of  hardware  or  software  development  costs.  As 
evidenced  by  these  results,  the  element  acquisition  cost  does  not 
vary  greatly  between  the  architectures.  In  addition,  when  the 
expected  useful  service  life  of  the  elements  is  considered,  the 
potential  difference  in  annual  lease  cost  becomes  less  significant. 
Based  on  the  small  difference  in  cost  Indicated  by  this  analysis, 
there  Is  no  clear  preference  among  the  alternative  architectures. 

(3)  Operation  and  Maintenance  Costs.  Since  personnel  costs 
represent  the  largest  single  contribution  to  total  operation  and 
maintenance  (04M)  costs,  the  projected  personnel  requirements  for 
each  alternative  architecture  were  evaluated.  As  part  of  this 
analysis  the  manning  requirements  for  each  element  type  (by  personnel 
category)  were  estimated  based  on  available  history  of  existing  ASC 


TABLE  IX.  PROJECTED  NETWORK  ELEMENT  ACQUISITION  COST 
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OPMENT COSTS. 

A ELEMENT  INVENTORIES  ARE  BASED  ON  TYPICAL  IMS  NETWORK  CONFIGURATIONS. 


and  AMPE  operations.  (A  further  discussion  of  manning  estimates  Is 
presented  In  Appendix  C.)  Average  annual  costs  by  personnel 
category  were  computed  based  on  available  DCA  cost  Information 
(Reference  G).  The  total  personnel  requirements  and  resultant 
annual  costs  were  computed  for  each  alternative  based  upon  the 
network  element  Inventories  developed  as  part  of  the  acquisition 
cost  analysis.  The  results  of  this  analysis  are  presented  In  Table 
X.  As  Indicated  In  this  Table,  Alternative  II,  The  Preferred 
Architecture,  represents  a savings  of  approximately  200  personnel 
which  would  result  In  as  estimated  annual  O&M  cost  reduction  of 
approximately  S4  million.  This  savings  results  primarily  from  the 
fact  that  Alternative  II  requires  fewer  nodal  element  Installations 
than  the  other  architectures  to  provide  the  same  performance, 
services  and  geographical  coverage.  Although  additional  components 
of  operation  and  maintenance  cost  (spares  and  backup  equipment, 
facilities  support,  and  utilities)  were  not  calculated  In  this 
analysis.  It  can  be  expected  that  consideration  of  additional  O&M 
factors  would  Increase  the  cost  advantage  of  Architecture  II  over 
the  other  alternatives. 

(4)  Summary  Cost  Comparison.  A first  order  estimate  of 
the  total  cost  of  the  Mid-Term  IAS  Is  approximately  S230  million 
per  year  (assumed  10  year  economic  life.)  The  total  difference 
In  cost  between  the  “best"  and  "worst"  alternatives  probably 
represents  less  than  5 percent  of  the  total  cost.  Considering  the 
Importance  of  04M  cost.  Architecture  II  probably  represents  the 
"least  cost"  alternative.  However,  the  cost  difference  Is  so  small 
that  selection  of  the  preferred  architecture  solely  on  this  basis  is 
not  recommended. 


(5)  Comparison  of  Preferred  Mid-Term  Architecture  to 
Projected  Baseline.  In  order  to  gain  Insight  Into  the  potential 
advantage  to  OCA  of  Implementing  the  preferred  Mid-Term  IAS 
Architecture,  the  comparative  cost  analysis  was  expanded  to  Include 
comparison  of  the  preferred  architecture  with  the  1983  baseline 
architecture  projected  to  a probably  1988  configuration.  The 
projected  baseline  architecture  used  In  this  analysis  would 
Incorporate  only  those  changes  and  upgrades  required  to  maintain 
current  system  capabilities.  The  projected  baseline,  when  compared 
with  the  preferred  Mid-Term  Architecture,  provides  a clear  Indication 
of  the  Impact  that  will  result  If  little  or  no  action  Is  taken  toward 
the  evolution  of  the  AUTODIN  system.  In  addition,  this  comparison 
clearly  emphasizes  the  potential  cost  savings  of  the  preferred 
architecture. 
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REFERENCE  f. 
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The  projected  1983  baseline  architecture  Is  based  on  the 
following  assumptions: 

o ASCs  retained  -In  operation  with  minimum  essential 
hardware/ software  subsystem  replacement 

o AMPEs  retained  In  all  current  locations  and  replaced  at  the 
end  of  their  useful  service  life  with  a "standardized-  AMPE. 

Base  on  current  DoO  policy,  the  projected  baseline  architecture 
Includes  provision  for  replacement  of  existing  AMPEs  with  some  form 
of  standardized  AMPE.  However,  because  these  equipments  would  not 
have  the  additional  capability  of  the  I-S/A  AMPE  used  In  the 
preferred  architecture.  It  Is  unrealistic  to  assume  that 
consolidation  could  be  achieved  In  the  projected  1983  baseline 
architecture.  Therefore,  the  number  of  AMPEs  projected  for  the  1988 
configuration  was  derived  from  current  and  planned  AMPE  requirements 
(see  Appendix  A). 

A comparison  of  projected  network  element  acquisition 
cost  for  the  preferred  architecture  versus  the  projected  baseline  Is 
presented  In  Table  XI.  As  Indicated  by  this  table,  total 
estimated  acquisition  cost  of  the  preferred  architecture  Is 
approximately  $3.3  million  greater  than  the  projected  baseline. 


The  comparison  of  operation  and  maintenance  personnel 
costs  for  the  preferred  architecture  versus  the  projected  baseline 
Is  presented  In  Table  XII.  As  evidenced  by  this  table,  the  pre- 
ferred architecture  offers  a potential  net  savings  of  over  2500 
personnel  with  a resultant  net  cost  savings  of  almost  $50  million 
per  year.  It  should  be  noted  that  the  cost  analysis  takes  Into 
account  the  fact  that  many  of  the  existing  and  planned  AMPE  sites 
eliminated  through  consolidation  will  revert  to  local  Terminal/ 
message  center  operation.  As  a result,  many  of  the  04M  personnel 
formerly  required  at  the  AMPE  sites  will  be  retained  for  operation 
of  the  terminal /message  centers  . The  magnitude  of  the  potential 
savings  Indicated  by  this  analysis  demonstrates  clear  opportunity 
for  significant  reduction  of  total  AUTODIN  system  operation  and 
maintenance  cost  through  Implementation  of  the  preferred 
Mid-Term  IAS  Architecture. 

c.  Recommendation.  Based  on  the  results  of  the  evaluation 
process,  the  preferred  architecture  described  In  paragraph  2 of  this 
section  Is  recommended  as  the  Mid-Term  Architecture  for  the 
Integrated  AUTODIN  System.  This  architecture  Is  fully  responsive  to 
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TABLE  XI.  NOOAL  ELEMENT  ACQUISITION  COST  COMPARISON 
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ASD  (C31 ) guidance  and  Is  capable  of  meeting  the  architectural 
objectives  for  the  Mid-Term  IAS  described  In  Section  I of  this 
report.  The  preferred  architecture  Is  consistent  with  the 
constraints  on  the  Mid-Term  IAS  defined  In  Section  II  (paragraph  2). 
and  Is  capable  of  providing  all  of  the  required  services  and 
functions  defined  for  the  Mid-Term  IAS  (Section  II,  paragraph  4).  In 
summary,  the  preferred  architecture  offers  significant  potential 
benefits  to  both  DCA  and  the  entire  DoO  AUTODIN  user  community: 

o Reduced  Cost  of  Ownership  - The  preferred  architecture  offers 
significant  opportunity  for  reduction  In  0AM  cost  through 
standardization  of  service/agency  message  processing  and 
coenunl cations  hardware,  software  and  operating  procedures. 
Additional  savings  will  result  from  consolidation  of  network 
service  elements  and  local  user  message  processing  elements  In 
the  access  area.  Finally,  a major  cost  savings  will  be 
possible  through  personnel  reduction  as  a result  of 
consolidation  of  access  area  AMPE  sites  Into  joint 
service/agency  multi-user  I-S/A  AMPE  configurations. 

o Enhanced  Survivability.  The  preferred  architecture  will  allow 
improved  access  reliability  for  users  through  multiple 
Interconnection  of  network  access  nodes  (I-S/A  AMPE  and  I-S/A 
AMPE(E)).  In  addition,  since  user  access  nodes  are  not 
dependent  on  higher  level  elements  for  most  normal  message 
traffic,  the  loss  of  a single  network  element  will  have  little 
effect  on  total  system  operation.  In  fact,  the  preferred 
architecture  provides  for  an  almost  continuous  graceful 
degradation  of  service  In  the  face  of  network  node/1  Ink 
losses. 

o Improvea  Performance.  The  preferred  architecture  will  permit 
the  Introduction  of  significant  new  telecommunication  services 
and  features.  In  addition,  the  Improved  access  arrangements 
and  distribution  of  service  nodes  throughout  the  access  area 
will  permit  Improved  speed  of  service  and  overall  network 
responsiveness  to  most  areas.  Furthermore,  the  flexibility 
Inherent  In  the  preferred  architecture  will  allow  the  future 
AUT00IN  system  to  accoomodate  many  unique  user  requirements 
without  penalty  to  other  users. 

o Evolutionary  Transition.  The  preferred  architecture  can  be 
Implemented  In  a smooth  evolutionary  process  from  the  19R3 
Near-Term  Architecture,  In  addition,  the  preferred 
architecture  provides  a framework  for  continued  evolutionary 
development  of  the  IAS  through  1988  and  beyond. 
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Among  the  potential  benefits  of  the  preferred  architecture,  the  most 
Important  may  well  be  Its  ability  to  evolve  In  a smooth  and  oroerly 
process  from  the  current  AUTODIN  network.  In  order  to  demonstrate 
the  feasibility  of  this  process,  the  final  Section  of  this  report, 
which  follows,  presents  a preliminary  transition  plan  for  the 
Implementation  of  the  preferred  architecture. 
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SECTION  IV 


TRANSITION 


1.  INTRODUCTION 

a.  Background.  In  accordance  with  ASD(C3I)  direction,  the 

IAS  will  evolve  in  a deliberate  and  continuous  fashion  from  today's 
communication  system  and  services  to  the  more  sophisticated 
communication  methods  of  the  future.  This  realistic  guidance 
precludes  the  possibility  of  any  single  "turnkey"  type  of  operation 
where  the  system  Is  replaced  by  another  at  some  pre-established  date. 
Hence,  the  need  for  a smooth  transition  over  the  next  decade  becomes 
paramount  to  the  IAS  architectural  strategy.  Continuity  of  service 
and  user  transparency  emerge  as  Important  transitional 
considerations.  The  Incremental  addition  of  new  network  elements 
(e.g.,  PSNs  and  I -S/A  AMPEs)  and  the  concomitant  phasing  out  of 
obsolete  equipment  (e.g.,  ASCs  and  AMPEs)  will  characterize  the 
evolution. 

The  first  cut  at  defining  a transition  plan  took  the  approach 
that  the  transition  must  be  performed  within  the  framework  of  a circa 
1990  IAS,  l.e.,  the  employment  of  equipment,  techniques,  and 
philosophies  must  be  consistent  with  the  full  range  of  potential 
circa  1990  architectures.  These  considerations  and  others  were 
factored  by  DCA  Into  a general  approach  to  achieving  evolutionary 
transition  and  were  presented  in  References  A and  H.  Under  that 
general  approach,  transition  strategies  were  postulated  for  two 
markedly  different,  but  feasible,  circa  1990  architectures:  one  based 
on  terrestrial  switching,  the  other  based  on  broadcast  satellite  use. 
It  was  assumed  that  the  architecture  selected  for  circa  1990  would 
lie  somewhere  between  these  extremes.  Since  each  of  the  alternatives 
considered,  although  differing  widely  In  the  backbone  architecture, 
proceeds  Initially  from  the  present  (1973)  architecture  in  the  same 
manner.  It  was  concluded  that  any  chosen  architecture  would  require 
the  same  sequence  of  events  in  the  near-term.  Consequently,  a single 
near-term  transition  approach  was  developed.  In  order  to  ensure  the 
continued  evolution  of  the  IAS  beyond  the  near-term,  a transition 
approach  for  the  mid- term  must  be  defined. 

b.  Purpose.  The  objective  of  this  section  of  the  report  Is 
to  demonstrate  the  feasibility  of  achieving  the  Mid-Term  IAS  In 
an  evolutionary  manner  by  defining  a preliminary  transition 
approach  for  the  Mid-Term. 


Paragraph  2 serves  as  a point  of  departure  to  the  Mid-Term 
IAS  transition  approach  by  reviewing  and  updating  near-term 
activities  and  milestones.  Paragraphs  3 through  8 postulate  a 
transition  strategy,  with  alternative  approaches  where  applicable, 
for  evolving  from  the  near-term  to  the  mid-term.  Finally,  the 
sequence  of  events,  milestones,  and  Interdependence  of  activities  for 
the  preliminary  transition  approach  are  presented  in  Paragraph  9. 

2.  NEAR-TERM  IAS 

The  Near-Term  IAS,  expected  to  be  fully  Implemented  by  late  1983, 
Is  depicted  In  Figure  20.  The  following  paragraphs  describe  the 
network  components,  functional  allocation,  and  transitional  approach 
for  achieving  the  Near-Term  IAS. 

a.  Network  Components.  In  the  near-term,  the  IAS  will  consist 
of  a set  of  elements  that  satisfy  validated  service  requirements 
with  no  technological  risk. 

(1)  AlfTODIN  Switching  Center  ( ASC ) . By  1983,  eleven  to 
thirteen  ASCs  will  be  in  operation  (six  government-owned  overseas, 
one  leased  In  Hawaii,  and  four  to  six  leased  in  CONUS).  Overseas 
ASCs  will  either  be  trunked  to  CONUS  ASCs  or  receive  trunking  via 
PSNs.  CONUS  ASCs  will  receive  their  trunking  throuqh  the  PSNs  when 
they  are  colocated  to  a PSN  (note:  CONUS  PSNs  will  be  colocated  and 
directly  connected  to  ASCs).  Those  ASCs  at  which  a PSN  will  not  be 
Initially  installed  will  use  dedicated  circuits  for  trunks. 

Functionally,  the  ASC  will  be  essentially  unchanged  from  what 
exists  today.  It  will  continue  to  provide  all  store-and- forward 
functions  such  as  message  retrieval.  Intercept  storage,  multiple 
address  processing,  code  conversion,  and  format  conversion. 

(2)  Packet  Switch  Node  (PSN).  Between  four  and  six 
Interconnected  CONUS  PSNs  will  be  In  place  and  operational  by  1983. 
Four  of  these  will  be  colocated  with  the  remaining  CONUS  ASCs  and 
will  have  a Mode  VI  serial  communications  Interface  capable  of 
multiple  virtual  connections  to  the  ASC.  The  PSNs  will  be 

i nterconnected  by  multiple  packet  trunks  operating  at  speeds  of  50 
kbps  or  greater  derived  from  common  carrier  facilities.  These  trunks 
will  be  link  encrypted. 

In  addition  to  providing  packet  switching  service  to  all 
AUTOOIN  II  subscribers,  the  PSN  will  terminate  AUTODIN  I,  Mode  1 
subscribers  e.g.,  AMPE.  All  traffic  so  received  will  be 
"cut- through"  to  a home  ASC  for  normal  AUTOOIN  I processing. 


Figure  20.  Near-Tern  IAS  Architecture 
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(3)  Automated  Message  Processing  Exchange  (AMPE).  Defense 
Agency  and  MILOEP  projections  Indicate  that  the  number  of  AMPEs  that 
will  be  operational  In  the  Near-Term  IAS  will  be  approximately  114. 
Installations  are  being  evaluated  on  a case-by-case  basis.  AMPEs 
will  be  terminated  on  either  PSNs  or  ASCs  using  AUTODIN  I.  Mode  I 
protocol.  For  availability  and  backup  purposes,  some  AMPEs  will 
probably  be  dual  connected,  l.e.,  connected  to  either  two  PSNs,  two 
ASCs,  or  a PSN  and  an  ASC.  In  each  case  the  connections  will  be 
extended  to  two  different  ASCs  to  receive  service. 

The  following  AMPE  types  will  be  In  place  and 
operational  In  the  Near-Term  IAS: 

o AMME  - Automated  Multi-Media  Exchange  (Army) 

o LOMX  - Local  Digital  Message  Exchange  (Navy) 

o NAVCOMPARS  *•  Naval  Communications  Processing  and  Routing 
System  (Navy)  ' 

o AF  AMPE  - Air  Force  Automated  Message  Processing  Exchange 

o ICATS  - Intermediate  Capacity  Automated  Telecommunications 
System  (Air  Force) 

o STREAMLINER  - Project  title  of  a family  of  Automated 
Communications  Facilities  (NSA) 

o DLA  - Defense  Logistics  Agency. 

o Near-Term  Inter-Service/Agency  AMPE 

All  of  the  AMPEs  to  varying  degrees  provide  and  will 
continue  to  provide  through  the  near-term: 

o AUTODIN  Terminal  System  Functions.  This  category  accounts  for 
all  functions  required  of  an  AUTODIN  subscriber  terminal. 

o Telecommunications  Center  Functions.  This  category  Includes 
those  functions  performed  by  a telecommunications  center. 

o Customer  Assistance  Functions.  This  category  Includes  those 
functions  that  can  be  performed  more  efficiently  at  a 
telecommunications  center  than  at  a user  facility. 


A specific  breakdown  of  these  categories  Is  provided  In  Reference  A. 

The  precise  functional  composition  of  the  AMPEs  varies 
by  Service/ Agency  as  each  AMPE  was  designed  and  developed 
Independently  to  provide  mission-oriented  functions  and  features. 
Consequently,  It  Is  difficult  for  each  AMPE  to  be  utilized  by 
subscribers  outside  the  Intended  community  of  interest.  AMPE  Phase  I 
and  Phase  11  Functional  Comparison  studies  have  addressed  this 
problem  and  concluded  that  there  Is  a large  amount  of  functional 
similarity  among  the  AMME,  IDMX,  NAVCOMPARS,  and  AF  AMPE  systems.  A 
third  phase  of  that  AMPE  comparison  analysis  Is  currently  underway  to 
determine  the  feasibility  of  establishing  functional  standards  and 
upgrading  existing  AMPEs  to  allow  Interservice  use  of  AMPEs  In  the 
near-term.  Additionally  the  feasibility  of  using  the  AF  AMPE  as  a 
baseline  for  a Near-Term  Inter-Service/Agency  AMPE  Is  under  study. 

(4)  Subscriber  Terminals.  The  Near-Term  IAS  will 
accommodate  a wide  variety  of  subscriber  terminals,  ranging 
from  Model -28  teletypewriters  to  sophisticated  software 
programmable  devices  such  as  Standard  Remote  Terminals  (SRTs) 
and  ADP  hosts. 

Depending  on  the  service  needs  of  the  subscriber, 
subscriber  terminals  will  be  terminated  on  AMPEs,  ASCs,  or  PSNs.  The 
various  termination  alternatives  available  to  a subscriber  are  shown 
In  Table  XIII.  While  It  would  appear  that  the  various  programmable 
devices  could  be  reprogrammed  to  Interface  directly  with  a PSN,  each 
device  should  be  considered  on  an  Individual  basis  to  determine  the 
desirability,  feasibility  and  cost-effectiveness  of  doing  so. 

(5)  Multiplexers.  Multiplexers  will  be  employed  where 
deemed  appropriate  to  save  communications  cost.  Multiplexers  will 
be  connected  to  a single  access  device  ( 1 .e. , AMPE,  ASC  or  PSN). 

b.  Near-Term  Transition  Strategy.  The  strategy  adopted  for 
transitioning  to  the  Near-Term  IAS  Is  characterized  by  a sequence 
of  events,  target  dates,  and  the  Interdependencies  of  events.  Table 
XIV  lists  the  required  activities  and  their  associated  target  dates 
In  chronological  order.  Figure  21  presents  the  transition 
activities  as  a milestone  chart  to  aid  In  visualizing  their 
Interdependencies. 

3.  MID-TERM  IAS 

In  keeping  with  the  ASO  (C3I)  guidance,  the  Mid-Term  IAS  will 
evolve  gracefully  from  the  Near-Term  IAS  to  the  selected  alternative 
of  the  Mid-Term  IAS.  Figure  22  depicts  the  Mid-Term  IAS  as  It  will 


TABLE  XIV.  NEAR-TERM  IAS  TRANSITION  PLAN 


Activity  CY  Target  Date 

Field  AMPEs  In  Progress 

Overseas  (O/S)  ASC  Memory  Upgrade  1978 

CONUS  ASC  Tape  Replacement  by  Disc  1978 

Start  Fielding  SRTs  1978 

Close  One  PAC  Area  ASC  (Buckner)  1978 

Close  Second  PAC  Area  ASC  (Clark)  1979 

Select  LMO  for  Near-Term  I -S/A  AMPE  1979 

IOC  AUTODIN  II  Phase  I (3  PSNs)  1979 

0/S  ASC  Tape,  Card  Reader  and  Printer  1980 

Replacement;  Upgrade  of  Patch>and-Test  Facilities 
Complete  Fielding  AUTODIN  II  Phase  I (4  PSNs)  1980 

Start  Phase  Out  CONUS  ASCs;  Rehome  1980 

Affected  Subscribers 

Field  Initial  0/S  AUTOOIN  II  PSNs  1981 

Start  AUTODIN  II  CONUS  Expansion  1981 

Complete  Fielding  AMPEs  1982 

Start  Fielding  Near-Term  I-S/A  AMPE  1982 

Complete  AUTOOIN  II  CONUS  Expansion  1983 

Complete  Phase  Out  (up  to  Four)  CONUS  ASCs  1983 

Near-Term  IAS  Architecture  Achieved  1983 
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Figure  22.  M1d~Ter»  IAS  Architecture 


appear  circa  1988  If  the  preferred  architecture  Is  Implemented. 

The  following  paragraphs  detail  the  components,  functional 
allocation,  and  strategy  for  achieving  an  evolutionary  transition. 

a.  General  Mid-Term  Objectives.  In  contrast  with  the  Near-Term 
IAS  which  Is  constrained  by  the  use  of  existing  technology  and 
equipment,  the  Mid-Term  IAS  begins  to  exploit  the  advantages  of 
state-of-the-art  coemunl cations  hardware  and  software  techniques. 
Accordingly  the  mid-term  transitional  strategy  Is  driven  by  the 
following  archl tectural  objectives: 

o Replace  equipment  as  It  becomes  outdated  with  new  or  augmented 
standardized  network  elements  (e.g.,  replace  AMPEs  with  I-S/A 
AMPEs) 

o Preserve  continuity  of  existing  network  services 

o Provide  for  needed  new  services 

o Develop  and  field  new  functional  capabilities  (e.g.,  end- 
to-end  encryption  with  key  distribution  centers) 

o Reduce  0AM  costs 

o Expand  AUT00IN  II  to  provide  a worldwide  data  backbone 

o Enhance  system  survivability 

o Enhance  tactical  and  allied  forces  Interoperability. 

b.  Transition  Issues.  With  respect  to  these  objectives,  there 
are  a number  of  transition  Issues  that  require  amplification  and 
resolution.  These  Include: 

o User  Transparency 

o Functional  Allocation/Real  location 

- Transfer  of  functional  responsibility  (e.g.,  ASC  to 
I«.S/A  AMPE(E)) 

- Field  testing  of  new  functional  capabilities  for  user 
acceptance 

o Replacement/Integration  Strategy 

- Incremental  addition  of  new  network  elements 

- "Cutover"  strategies 


- Phasing  out  of  obsolete  or  non-cost  effective  equipment 

- Rehoming  affected  subscribers 

- Impact  on  remaining  network  elements 
o Overseas  (0/S)  Implications 

These  Issues  and  objectives  have  been  factored  Into  an  overall  IAS 
transition  strategy  which  can  In  turn  be  subdivided  Into  more 
detailed  lower  level  (network  element)  transition  strategies.  The 
Intent  of  the  subsequent  discussions  Is  to  Illustrate  the  overall 
Mid-Term  transition  strategy  by  Identifying  transition  alternatives 
at  each  level. 

c.  Network  Elements.  In  addition  to  the  near-term  network 
elements,  which  will  exist  Into  and  in  some  Instances  through  the 
mid-term,  a number  of  new  network  elements  must  be  Implemented  In  the 
mid-term. 


(1)  I n ter^Serv  1 ce/ Agency  AMPEs  ( I*-S/A  AMPE  and  I-S/A 
AMPE(E)).  The  I-S/A  AMPE  and  I-S/A  AMPE(E)  will  be  used  to  satisfy 
all  requirements  for  new  or  replacement  AMPEs  as  well  as  providing 
the  services  and  functions  needed  In  the  IAS.  An  enhanced  version  of 
this  network  element,  the  I-S/A  AMPE(E).  In  addition  to  providing 
AMPE  functions  and  services,  will  assume  the  functional  role  of  the 
ASC  and  will  provide  network  services  currently  outside  the  scope  of 
the  Near-Term  IAS. 

(2)  Centralized  Service  Facility  (Contingency  Option). 
Although  the  preferred  Mid-Term  IAS  architecture  does  not  Include 
this  element,  the  CSF  represents  a potential  system  level  transition 
option.  This  option  will  be  exercised  only  In  the  event  that  new 
requirements  emerge  that  cannot  be  accommodated  within  the  I-S/A 
AMPE(E)  program. 

(3)  Common  Family  of  Terminals  (CFT).  A new  generation  of 
subscriber  equipment  will  be  Introduced  In  the  Mid-Term  IAS  time 
frame. 

(4)  Security  Components.  An  end-to-end  encryption  (E3) 
capability  derived  from  the  BLACKER  hardware  and  software 
developments  will  be  Introduced  by  the  Mid-Term  IAS. 


d.  Transition  Objectives.  Relative  to  the  Mld'-Term  IAS  network 
components , transition  planning  focuses  on  meeting  the  following 
specific  transition  objectives: 

o Implementation  of  the  NS/A  AM PE  Family  of  Equipments 

o Expansion  of  the  PSN  backbone 

o Introduction  of  the  CFT 

o Integration  of  E3  security  Into  the  operational  network. 

The  transition  Issues  relative  to  each  of  these  objectives  are 
discussed  In  detail  In  the  remainder  of  this  section. 

4.  IMPLEMENTATION  OF  NS/A  AMPE  FAMILY 

a.  NS/A  AMPE  Family  Development  Approach.  The  NS/A  program  is 
based  on  the  development  of  a common  standardized  set  of  hardware  and 
software  modules.  The  modular  approach  of  this  program  coupled  with 
the  use  of  a high  order  compiler  language  (HOL)  for  software 
development  should  alleviate  critical  manpower  and  unique  software 
support  requirements  that  characterized  the  Independent  AMPE 
programs.  Accordingly,  this  approach  should  result  In  reduced 
maintenance  costs  and  greater  flexibility  In  sizing  and  configuring 
the  access  area.  Also  Inherent  to  this  approach  Is  the  potential  for 
providing  specific  functional  modules  locally  where  required  or 
desired. 

b.  NS/A  AMPE  Roles.  The  NS/A  AMPE  family  of  equipment  will 
fill  three  distinct  roles  In  the  Mid-Term  IAS: 

o Replacement  of  AMPEs 

o Replacement  of  ASC 

o Provision  of  new  IAS  service 

The  NS/A  AMPE  family  Implementation  approach  reflects  these  three 
distinct  roles.  Accordingly,  the  following  subsections  present  the 
transition  Issues  relevant  to  the  NS/A  AMPE  In  each  of  its  projected 
roles. 


c.  AMPE  Replacement.  Each  I-S/A  AMPE  Implementation,  enhanced 
or  otherwise,  will  provide  certain  basic  capabilities  that  are 
currently  allocated  to  the  AMPE,  e.g.,  journalling,  retrieval , 
Intercept,  PLA/RI  conversion,  format  and  code  conversion,  and 
terminal  Interface.  In  other  words,  every  I-S/A  AMPE  and  the 
enhanced  version  will  function  as  an  AMPE  replacement  as  a minimum. 
The  precise  configuration  of  an  NS/A  AMPE  will  vary  by  location  but 
will  be  based  on  the  coimnon  family  of  hardware/software  modules. 
Unique  functions  will  be  accommodated  on  an  "as  required"  basis. 

As  noted  previously,  the  lack  of  AMPE  standardization  makes 
It  difficult  for  a subscriber  outside  the  Intended  community  of 
Interest  to  use  an  AMPE.  The  NS/A  AMPE,  however,  will  provide 
service  to  all  Service/ Agency  users.  Furthermore,  R/Y  consolidation 
will  also  be  achieved  In  this  network  element.  Consequently,  as  the 
IAS  evolves.  It  Is  anticipated  that  the  replacement  of  AMPEs  with 
I-S/A  AMPEs  will  lead  to  consolidation  of  AMPE  sites  and  an 
accompanying  reduction  In  maintenance  cost.  (Reference  Appendix  A). 

The  target  date  for  the  AMPE  replacement  modules  of  the  I-S/A 
AMPE  Is  scheduled  for  the  latter  part  of  1983.  Subsequent  to  that 
milestone  all  AMPE  Implementations,  new  or  replacement,  will  be  I-S/A 
AMPEs.  Furthermore,  any  AMPEs  scheduled  to  be  replaced  In  the  6 
month  period  Immediately  preceding  Introduction  of  the  NS/A  AMPE 
should  be  delayed  so  that  they  can  be  replaced  by  an  I-S/A  AMPE. 
Ultimately  all  current  AMPEs  will  be  phased  out  In  favor  of  the  I-S/A 
AMPE. 

The  actual  AMPE  replacement  strategy  and  total  I-S/A  AMPE 
requirements  will  be  defined  by  OCA  In  coordination  with  potential 
Service/Agency  users.  Nevertheless,  certain  characteristics  of  the 
transition  can  be  rather  safely  stated.  These  relate  to  the 
transition  Issues  of: 

o Cutover 

o General  Replacement  Strategy 
o Survlvabnity/Avallablllty 
o Overseas  Implications 
o Support  Requl rements 

These  transition  Issues  are  discussed  In  the  following  subparagraphs. 
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(1)  Cutover  to  I -S/A  AMPE.  Since  continuity  of  service  and 
user  transparency  are  primary  transition  objectives,  the  replacement 
of  an  AH PE  Mill  require  a smooth  cutover.  Three  alternatives  have 
been  considered  toward  this  end: 
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o Alternative  1:  Physically  Install  an  NS/A  AMPE  and  establish 
circuits  to  two  higher  level  elements.  Dual  capture  "back 
side*  AMPE  Circuits  on  both  AMPE  and  I -S/A  AMPE. 

Operationally  test  NS/A  AMPE.  Cutover  from  AMPE  to  I-S/A 
AMPE  and  close  down  AMPE. 

o Alternative  2:  Physically  Install  and  home  I-S/A  AMPE  as 
above.  Tie  AMPE  onto  back  side  of  NS/A  AMPE  In  addition  to 
Its  normal  homing.  Individually  cutover  back  side  AMPE 
circuits.  Close  down  AMPE. 

o Alternative  3:  Rehome  back  side  AMPE  users  to  nearby  nodes 
(l.e.,  PSNs,  I-S/A  AMPE(E),  I-S/A  AMPE,  or  AMPEs).  Close  down 
and  physically  remove  AMPE.  Install  I-S/A  AMPE  and  home  to 
two  higher  level  elements.  Re-establish  back  side  users  on 
the  NS/ A AMPE. 

Alternative  3 significantly  Impacts  other  network 
elements  and  should  be  considered  only  when  physical  limitations 
demand  AMPE  removal  prior  to  I-S/A  AMPE  Installation.  Alternative  1 
Is  preferred  over  Alternative  2 because  It  allows  I-S/A  AMPE  test  and 
evaluation  In  a near-operational  environment  prior  to  final  cutover. 
Determination  of  a preferred  alternative  will  be  Influenced  by  local 
factors  such  as  circuit  cost  and  availability. 

(2)  AMPE  Replacement  Strategy.  The  transition  from  AMPEs  to 
NS/A  AMPEs  will  be  marked  by  the  Incremental  addition  of  I-S/A  AMPEs 
to  the  network  over  the  next  dozen  years  primarily  based  on  the 
remaining  useful  service  life  of  existing  AMPEs.  Consequently,  the 
replacement  of  some  AMPEs  can  be  absorbed  by  I-S/A  AMPEs  that  were 
fielded  for  other  reasons  (l.e.,  to  replace  a nearby  AMPE  or  to 
satisfy  new  requirements  for  I-S/A  AMPE  service).  This  will  happen 
when  an  AMPE  located  close  to  an  operational  NS/A  AMPE  requires 
replacement.  In  this  event,  AMPE  subscribers  could  be  rehomed  to  the 
nearby  NS/A  AMPE  (note:  It  may  not  be  the  same  I-S/A  AMPE  for  all 
users;  In  particular,  remote  users)  as  an  Interim  measure,  followed 
by  cutover  and  removal  of  the  AMPE.  Alternatively,  the  AMPE  Itself 
can  be  rehomed  to  the  nearby  I-S/A  AMPE  and  each  subscriber  cutover 
Independently  (as  In  Alternative  2 above).  Both  of  these  options  are 
consistent  with  transition  objectives  and  each  allows  for  minimizing 
transmission  costs  by  addressing  each  subscriber  Individually. 
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(3)  Survlvablllty/Avallablllty.  To  enhance  survivability 
and  availability,  I— S/A  AMPEs  will  probably  be  dual  homed  to  two 
higher  level  elements.  Specifically,  the  I-S/A  AMPE  can  be 
terminated  on  two  PSNs,  two  I-S/A  AMPE(E)s,  or  one  PSN  and  one  I -S/A 
AMPE(E).  As  discussed  In  Section  III  It  Is  preferable  to  connect  the 
I-S/A  AMPE  to  a PSN  and  an  I-S/A  AMPE(E)  In  order  to  facilitate  both 
optimum  traffic  routing  and  enhanced  survivability.  The  AUTODIN 
Management  Index  (AMIE),  the  Worldwide  AUTOOIN  Restore 1 Plan  and 
other  management  plans  and  data  bases  will  be  modified  at  an  early 
date  to  Incorporate  the  I-S/A  AMPEs  and  to  take  advantage  of  the 
survivability  and  availability  features  the  I-S/A  AMPE  will  bring  to 
the  IAS.  In  addition  to  the  ability  of  the  network  to  provide  more 
locations  for  service  to  all  users,  the  cost  factors  of  providing 
capabilities  such  as  dual  homing  will  be  favorably  affected. 

(4)  Overseas  AMPE  Implications.  AMPE  equipments  located 
overseas  may  reach  the  end  of  their  useful  service  life  and  require 
replacement  prior  to  full  Introduction  of  PSN  or  I-S/A  AMPE(E) 
service  overseas.  In  this  event,  homing  of  replacement  I-S/A  AMPEs 
presents  two  options.  The  I* S/A  AMPEs  can  be  homed  to  CONUS  PSNs  or 
I-S/A  AMPE(E)s;  however,  the  use  of  Intercontinental  trunks  for  this 
purpose  Is  undesirable  from  both  cost  and  survivability 
considerations.  Alternatively,  I-S/A  AMPEs  could  be  homed  to  a 
remaining  overseas  ASC  via  the  available  AUTOOIN  I,  Mode  I Interface. 
This  would  provide  an  Interim  solution  until  eventual  ASC 
replacement. 

(5)  AMPE  Support  Requirements.  Based  on  AMPE  service  life 
projections  and  Installation  schedules,  a significant  number  of  AMPEs 
will  not  require  replacement  In  the  Mid-Term  time  frame  and,  therefore, 
must  be  supported  Into  the  far- term. 

d.  ASC  Replacement.  The  enhanced  I-S/A  AMPE  Is  a modular 
expansion  of  the  AMPE  replacement  I-S/A  AMPE  that  contains  (In 
addition  to  Its  AMPE  replacement  functions)  all  of  the  functions  of 
the  ASC,  e.g.,  message  switching,  multiple  address  routing.  Because 
of  the  high  cost  associated  with  the  operation  and  maintenance  of 
ASCs,  a high  priority  will  be  placed  on  phasing  out  the  ASCs.  The 
Initial  installations  of  I-S/A  AMPE(E)s,  projected  for  early  1984, 
will  be  carefully  planned  so  that  each  Installation  Is  accompanied  by 
the  closure  of  an  ASC. 
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Because  It  Is  undesirable  to  make  a transition  decision  that 
will  oe  reversed  by  a later  transition  consideration.  ASC  closings 
cannot  be  addressed  Independently.  Care  must  be  taken  with  each 
transition  step  so  that  a smoother  transition  to  the  final  Mid-Term 
configuration  can  be  achieved. 

In  the  near-term  the  number  of  ASCs  In  CONUS  and  Overseas 
will  be  reduced.  With  the  Implementation  of  I-S/A  AMPEs  and 
additional  PSNs.  the  ASCs  will  be  required  only  to  perform  the 
message  processing  function  for  store-and- forward  traffic.  It  Is 
these  functions  which  the  I-S/A  AMPE(E)  will  be  designed  to  perform. 
Hence  elimination  of  ASCs  becomes  possible. 

(1)  Overseas  ASC  Trunking.  The  primary  Issue  In  overseas 
trunking  Is  maintaining  diversity  In  the  event  of  failures.  The 
preferred  connection  for  trunking  Is  via  the  PSNs  but  additional 
trunk  connections  e.g.,  0/S  I-S/A  AMPE(E)  to  CONUS  PSN  may  be 
desirable  until  sufficient  PSNs  are  fielded  overseas.  Prior  to 
fielding  the  I-S/A  AMPE(E),  the  ASCs  will  In  some  cases  maintain  their 
own  trunking  sub  net.  When  the  I-S/A  AMPE(E)  Is  fielded,  connection 
between  ASCs  would  be  maintained  only  If  PSN  connections  are  found  to 
be  Inssuflclent. 

(2)  Rehoming  Directly  Connected  ASC  Subscribers.  AUTOOIN  I 
subscriber  terminals  that  are  directly  connected  to  an  ASC  must  be 
rehomed.  Rehoming  of  terminals  will  be  evaluated  on  a case-by-case 
basis.  AUTOOIN  I terminals  can  be  rehomed  alternatively  to  an  I-S/A 
AMPE,  I-S/A  AMPE(E).  or.  If  a Mode  I terminal,  to  an  I-S/A  AMPE(E)  via 
PSN  cut-through.  Consideration  for  each  affected  terminal  should  be 
given  to  minimizing  transmission  cost  and  to  the  final  Mid-Term  IAS 
configuration.  A less  attractive  rehoming  option  Is  to  rehome  to  an 
AMPE.  This  would  result  In  another  rehoming,  however,  when  that  AMPE 
Is  phased  out.  This  Is  Inconsistent  with  planning  for  a smooth 
transition. 

(3)  ASC -PSN  Connections.  CONUS  ASCs  are  connected  to  the 
PSN  for  two  purposes: 

o to  receive  CONUS  trunking 

o to  service  message  switching  requests  from  remote  CONUS 
subscribers 

Once  the  overseas  trunking  and  direct  subscriber  connection  problems 
are  resolved,  the  ASC-to-PSN  connection  will  only  be  used  for  message 
switching  service  requests.  The  PSNs  must  then  route  these  requests 
to  an  I-S/A  AMPE(E).  This  will  permit  ASC  deactivation. 
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(4)  Cutover.  The  actual  Installation  of  an  I-S/A  AMPE(E)  Is 
Identical  In  cutover  procedures  to  the  Installation  of  an  I-S/A  AMPE 
with  one  exception.  That  occurs  when  the  I-S/A  AMPE(E)  Is  being 
Installed  In  a location  that  has  an  I»S/A  AMPE.  Those  modules 
necessary  to  upgrade  the  system  to  Its  enhanced  version  must  be 

1 oeded/conf 1 gured  without  shutting  down  the  system.  This  Is  In 
keeping  with  continuity  of  service  and  user  transparency  objectives. 

(5)  I —S/A  AMPE(E)  Site  Selection.  Cutover  transition 
considerations  that  should  be  applied  In  selecting  sites  to  receive 
the  ASC  replacements  are  discussed  In  the  following  subparagraphs. 

Local  Service.  All  I-S/A  AMPE ( E ) s will  be  deployed  as 
AMPE  replacements  and/or  I-S/A  AMPE  upgrades  and  will  reside 
functionally  In  the  access  area.  They  will  be  dual  connected  to  the 
PSN  backbone  using  the  Mode  VI  Host  Interface.  I-S/A  AMPE(E)s  should 
be  strategically  placed  to  minimize  transmission  costs  by  taking 
advantage  of  the  local  service  Implications  of  the  access  node  and 
the  direct  homing  potential  for  nearby  AMPEs  and  I-S/A  AMPEs. 

Facilities.  Since  the  I-S/A  AMPE(E)  Is  of  greater 
Importance  than  the  I-S/A  AMPE  to  the  network.  It  Is  envisioned  that 
It  will  require  additional  support  In  the  form  of  an  uninterruptible 
power  source  (UPS)  and  a backup  power  plant.  Thus  consideration 
should  be  given  to  former  ASC  sites  since  these  sites  generally 
possess  the  needed  power  facilities  as  well  as  other  necessary 
facilities,  e.g..  a patch-and-test  facility  (P4TF) . 

Survivability.  Since  enhanced  system  survivability  Is  a 
system  goal,  extra  consideration  should  be  accorded  to  facilities 
with  unique  survivability  provisions  (e.g.,  hardening,  unlterruptable 
power  supply). 

Expandability.  The  primary  purpose  for  Initial  I-S/A 
AMPE(E)  Installations  Is  to  facilitate  ASC  phaseout.  Consequently, 
the  primary  emphasis  during  planning  stages  will  be  to  identify  those 
I-S/A  AMPE(E)  sites  that  will  permit  ASC  closings.  Future 
requirements  for  I-S/A  AMPE(E)  service  can  be  addressed  later,  since 
these  needs  can  be  satisfied  by  upgrading  existing  I-S/A  AMPE  sites. 

e.  New  Services.  As  currently  projected,  requirements  for  new 
network  services,  such  as  mailbox  and  teleconferencing,  will  be 
satisfied  through  modular  expansion  of  the  I-S/A  AMPE(E).  Each  new 
service  will  be  test  marketed  by  Introducing  It  Initially  to  a 
limited  number  of  subscribers  on  a pilot  demonstration  basis  using 
RAO  funds.  The  first  of  these  pilot  demonstrations  Is  not 
anticipated  before  1985. 
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Th«  modular  Implementation  of  these  services  offers  a great 
deal  of  flexibility  In  configuring  I-S/A  AMPE(E)s  to  provide  these 
services.  As  an  extreme,  these  modules  could  conceivably  be 
configured  In  a network  component  other  than  an  I-S/A  AMPE(E)  (e.g., 
to  provide  backup  capability).  Requirements  for  these  modules  will 
be  evaluated  on  a case-by-case  basis. 

5.  EXPANSION  OF  PACKET  SWITCH  NODE  (PSN)  BACKBONE 

The  Mid-Term  IAS  will  mark  the  emergence  of  a worldwide  data 
backbone.  PSNs  will  be  deployed  In  both  CONUS  and  overseas  to 
augment  the  near-term  8 node  network.  As  the  data  backbone  evolves, 
transition  objectives  and  Issues  take  on  the  following  significance. 

a.  PSN  Expansion  - Sequence  of  Events.  As  stated  previously,  It 
Is  undesirable  to  execute  a transition  step  that  will  be  reversed  by 
subsequent  transition  steps.  In  this  regard,  each  step  of  the 
transition  should  reflect  as  closely  as  possible  the  final  Mid-Term 
configuration.  In  this  context,  requirements  for  PSNs  must  be 
Identified  during  planning  stages  through  consideration  of  the 
deployment  of  other  Mid-Term  network  components,  specifically,  the 
I-S/A  AMPE,  I-S/A  AMPE(E)  and  CFT.  The  Installation  of  PSNs  should 
be  closely  coordinated  with  the  schedules  for  the  other  components  so 
that  PSNs  are  fielded  first.  This  will  facilitate  a smooth 
transition  by  eliminating  needless  Iterative  rehoming  of  subscriber 
equipment  and  access  nodes.  Rehoming  Is  unavoidable  In  an  evolving 
network;  but,  It  can  be  kept  to  a minimum  through  careful  transition 
pi annlng. 

b.  Overseas  PSN  Implications.  As  enhanced  survivability  Is  a 
system  objective,  consideration  should  be  given  to  deploying  smaller, 
more  mobile  PSNs  overseas.  Implementation  of  the  PSN  TAC  (Terminal 
Access  Control)  functions  In  the  I-S/A  AMPEs  should  facilitate  a 
smaller  PSN  configuration. 

5.  INTRODUCTION  OF  THE  COMMON  FAMILY  OF  SUBSCRIBER  TERMINALS 
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The  Mid-Term  IAS  will  be  required  to  support  a mix  of 
subscriber  terminals  that  fall  Into  one  of  the  following  generic 
c categories: 

o AUTOOIN  I Terminals 
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o AUTOOIN  II  Terminals 
o AUTOOIN  II  Hosts 


o Coninon  Family  AUTOOIN  Terminals  (CFT) 
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A*  the  IAS  evolves,  the  distinction  between  these  different 
categories  of  terminals  will  disappear  as  the  CFT  will  satisfy  all 
subscriber  requirements.  Beginning  In  1984,  the  CFT  will  be  used 
exclusively  to  fulfill  needs  for  new  or  replacement  subscriber 
equipment.  Exceptions  to  this  policy  will  be  evaluated  on  a case- 
by-case  basis. 

All  categories  of  equipments  are  expected  to  exist  through  the 
Mid-Term.  Depending  on  the  service  needs  of  the  subscriber, 
terminals  will  be  terminated  on  AMPEs,  I-S/A  AMPEs,  I-S/A  AMPE(E)s, 
or  PSNs.  Table  XV  shows  the  termination  alternatives  available  to 
a subscriber.  Also,  with  the  I-S/A  AMPE(E)  located  functionally  In 
the  access  area,  dual  homing  may  be  employed  for  those  programmable 
terminals  capable  of  selecting  the  best  path  relative  to  the  service 
desired.  Such  terminals  would  be  dual  homed  to  a PSN  and  an  I-S/A 
AMPE(E). 

7.  INTEGRATION  OF  SECURITY  COMPONENTS 

The  Mid-Term  IAS  will  feature  the  Introduction  of  an  end-to-end 
encryption  (E3)  capability.  This  capability  will  be  based  on  the  use 
of  BLACKER  hardware  and  software  components.  Transition 
considerations  for  these  elements  are  provided  In  a separate 
classified  appendix  (Appendix  B). 

8.  MILESTONES  AND  SCHEDULE 

The  overall  strategy  for  transitioning  from  the  Near-Term  to  the 
Mid-Term  IAS  can  be  postulated  In  terms  of  a sequence  of  events,  target 
dates,  and  the  Interdependencies  of  events.  The  transition 
considerations  discussed  In  the  preceding  paragraphs  have  been 
factored  Into  a recommended  transition  plan  as  shown  In  Table  XVI 
and  Figure  23.  Table  XVI  lists  the  required  activities  and  their 
associated  target  dates  In  chronological  order.  Figure  23  presents 
these  activities  as  a milestone  chart  to  help  visualize  their 
Interdependencies. 

Although  the  ultimate  transition  strategy  may  deviate  slightly 
from  what  Is  postulated,  the  reconmended  approach  does,  In  fact, 
demonstrate  the  feasibility  of  achieving  the  Mid-Term  IAS  In  a 
deliberate  and  continuous  manner.  It  also  provides  the  framework  for 
subsequent,  more  detailed  network  element  transition  plans. 
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Mid-Tern  IAS  Milestones 


TABLE  XVI.  MID-TERM  IAS  TRANSITION  PLAN 


Activity  CY  Target  Data 

a.  Start  Development  of  I-S/A  AMPE  Fanlly  of  Nodes  1979 

b.  Start  Development  of  Common  User  Family  of  1979 

Terminals 

c.  Start  Mid-Term  Topology  Design  A Related  Studies  1979 

d.  Start  Development  of  New  Services  and  Functions  1960 

e.  Detailed  Definition  of  Functions  for  I-S/A  AMPE  1980 

f.  HOL  Decision  (DoD)  1961 

g.  Begin  development  of  HOL  Software  for  NS/A  AMPE  1981 

h.  Mid-Term  IAS  System  Implementation  Plan  Development  1981 

I.  Definition  of  Services  and  Functions  for  I-S/A  1962 

AMPE(E) 

J.  Begin  PSN  Expansion  (0/S  and  CONUS  as  required)  1964 

k.  Stop  Fielding  Near-Term  I-S/A  AMPE  1984 

l.  Begin  Fielding  I-S/A  AMPE  (AMPE  Replacement)  1964 

m.  Begin  Fielding  Comeon  Family  of  Terminals  1964 

n.  Begin  AMPE  Phaseout  1964 

o.  Begin  Fielding  I-S/A  AMPE(E)  1965 

p.  Begin  Phaseout  of  Remaining  ASCs  1965 

q.  Begin  Fielding  End-to-End  Encryption  Equipment  1966 

r.  Complete  Phaseout  of  0/S  ASCs  1967 

s.  Complete  Fielding  NS/A  (AMPEHE)  1966 


TABLE  XVI.  MID-TERM  IAS  TRANSITION  PLAN  (Continued) 


t.  Complete  Phaseout  of  CONUS  ASCs 

u.  Complete  a Worldwide  PSN  Backbone 

v.  Mid-Term  IAS  Architecture  Achieved 

w.  Complete  AMPE  Phaseout 
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AMPE  AND  INTER-SERVICE/AGENCY  AMPE 
POPULATION  FOR  1982-1990 
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I.  INTRODUCTION 


This  analysis  was  performed  In  order  to  define  the  projected 
requirements  for  the  Inter-Service/Agency  Automated  Message 
Processing  Exchange  (I-S/A  AMPE)  as  an  Input  to  the  definition  of 
the  Mid-Term  Architecture  for  the  Integrated  AUTOOIN  System  (IAS). 
The  analysis  Includes  definition  of  the  current  and  projected 
Automated  Message  Exchange  (AMPE)  population  through  the  mid- term 
and  development  of  a postulated  replacement  strategy.  The  actual 
I-S/A  AMPE- for- AMPE  replacement  strategy  and  I-S/A  AMPE  requirements 
will  be  defined  by  OCA  In  coordination  with  the  AMPE  and  potential 
I-S/A  AMPE  users.  This  analysis  and  the  projections  presented  here 
are  Intended  for  planning  purposes  only. 

II.  ASSUMPTIONS 

The  assumptions  that  form  the  basis  for  the  following  analysis 

are: 


1.  A standardized  AMPE  for  inter- service/agency  use  will  be 
available  by  the  end  of  1981  for  deployment  beginning  In  1982. 
This  Near  Term  Inter-Service/Agency  AMPE  will  be  developed  by  a 
lead  MILOEP  (.most  likely  Air  Force),  primarily  to  meet  near-term 
needs  of  the  Air  Force  and  Defense  Logistics  Agency. 

2.  The  Inter-Service/ Agency  AMPE  defined  by  the  IAS  Mid-Term 
Architecture  will  be  available  for  deployment  In  the 

1964  time  frame.  Some  overlap  with  deployment  of  the  Near-Term 
I-S/A  AMPEs  may  occur. 


3.  The  current  projected  AMPE  population  by  1983  will  be  114, 
broken  down  as  follows: 

Servlce/Aqency  Number  of  AMPEs 


Navy  22 
Army  20 
Air  Force  22 
NSA  31 
OLA  19 


TOTAL  114 


The  analysis  assumes  that  Army  and  Navy  projected  AMPE  Installations 
for  the  remainder  of  the  near-term  (through  1982)  will  proceed  as 
planned.  Air  Force  projected  AMPE  installations  for  1981  will  be 
delayed  and,  together  with  the  projected  Installations  for  1982, 
be  satisfied  by  Near-Term  I-S/A  AMPEs  commencing  In  1982. 


4.  Existing  OLA  AMPEs  (fielded  In  the  early  1970s)  will  all  be 
replaced  between  1982  and  1984. 

5.  The  service  life  of  all  current  AMPEs  Is  8 to  10  years. 

Although  many  AMPEs  are  able  to  remain  In  place  longer,  the  8 to 
10  year  figure  commonly  used  for  economic  analyses  Is  used  as  a 
worst  case. 

6.  AMPE  requirements  Identified  for  the  period  1978-1982  Indicate 
a growth  In  AMPE  population  of  81  to  91  per  year.  This  rate  of 
growth  In  the  number  of  AMPEs  Is  not  expected  to  continue  beyond 
1982  for  two  reasons,  however.  First,  the  Near-Term  I-S/A  AMPE  that 
meets  multi-user  requirements  will  be  available.  Secondly,  a 
substantial  number  of  AMPE  sites  will  exist  as  a result  of  near- 
term  Installation  growth.  In  the  post-1982  period,  therefore. 

It  will  become  Increasingly  likely  that  new  subscriber  requirements 
can  be  satisfied  through  use  of  existing  AMPEs  or  I-S/A  AMPEs 
rather  than  through  new  system  Installations.  A reduced  rate  of 
growth  (41)  was,  therefore,  used  for  projecting  the  I-S/A  AMPE 
population  beyond  1982.  Oemand  for  new  systems  beyond  the  near- 
tenn  Is  assumed  at  a four  percent  growth  rate  per  year.  It  was 
further  assumed  that  one  percent  will  be  absorbed  through  consolidation 
of  existing  I-S/A  AMPEs.  The  remaining  three  percent  will  be 
satisfied  by  new  I-S/A  AMPE  Installations. 

7.  All  NSA  STREAMLINERS  will  be  replaced  between  1985  and 

1987,  based  on  their  actual  fielding  dates  (1977-1978)  and  assumed 
service  life  (Assumption  5).  The  location  of  five  STREAMLINER 
systems  was  unavailable  In  time  for  Inclusion  In  this  analysis. 

A one-for-one  replacement  of  these  five  systems  Is  assumed. 

8.  LDMX-I  systems  (single  70/45  processor)  fielded  during  the 
remainder  of  the  near-term,  as  the  result  of  NAVC0MPARS-1  systems 
(dual  70/45  processors)  being  replaced  by  NAYCOMPARS-IIs,  will  be 
replaced  In  the  1985-1987  time  frame  based  on  the  8 to  10  year 
service  life  of  the  hardware. 

9.  CONUS  AMPEs  within  50  miles  of  each  other  will  be  replaced  by 
a single  I-S/A  AMPE  or  by  two  I-S/A  AMPEs  If  more  than  three  AMPEs 
are  Involved.  Otherwise  I-S/A  AMPE  for  AMPE  replacement  will  be 
on  a one-for-one  basis  In  CONUS. 

10.  Overseas  AMPEs  that  are  colocated  will  be  replaced  by  a single 
I-S/A  AMPE  or  by  two  I-S/A  AMPEs  If  more  than  two  AMPEs  are 
Involved.  Otherwise  I-S/A  AMPE- for- AMPE  replacement  will  be  on  a 
one-for-one  basis  overseas. 
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II.  AMPE  testbed  facilities  will  remain  In  place  as  long  as  any 
AMPEs  of  the  corresponding  Service  or  Agency  are  still  In  the 
field.  Furthermore,  testbed  facilities  will  not  be  replaced  with 
I-S/A  AMPEs  nor  will  they  be  counted  In  any  CONUS  AMPE  consolidation 
as  described  by  Assumption  9. 

III.  ANALYSIS 

A total  of  114  AMPEs  are  currently  projected  to  be  In  place  by 
the  end  of  1982,  thirty-one  of  which  are  NSA  STREAMLINER  systems. 

An  analysis  of  the  AMPEs  was  performed  on  a case-by-case  basis 
from  which  replacement  dates  and  consolidation  strategies  were 
developed  using  the  assumptions  listed  In  Section  II.  The  results 
of  the  analysis  are  presented  In  Table  A-I.  The  83  projected 
AMPEs  belonging  to  Army,  Navy,  Air  Force,  and  DLA  are  listed  by 
geographic  location.  Also  shown  Is  the  time  frame  In  which  each 
AMPE  will  require  replacement  and  consolidation  strategy. 

Additional  notes  related  to  Table  A-I  are: 

. STREAMLINER  locations  are  CONFIDENTIAL  and  are  therefore 
not  listed 

. Army  AMPEs  that  are  not  already  In  place  have  the  projected 
Installation  date  listed  along  with  the  location  name 

. Navy  AMPEs  are  Identified  by  system  type  (LDMX  or  NAVCOMPARS) 
and  generation  (I  or  II).  Those  that  are  not  yet  In  place 
have  the  projected  Installation  date  listed  as  well. 

. Eleven  (11)  of  the  Air  Force  AMPE  locations  are  labeled 
"NEW".  These  represent  1982  and  delayed  1981  requirements 
(Assumption  3)  that  will  be  satisfied  by  I-S/A  AMPEs  rather 
than  the  current  ATP  5/6  program.  Seven  of  the  requirements 
are  met  by  five  new  I-S/A  AMPEs  Installed  specifically  to 
meet  those  requirements.  The  remaining  four  requirements 
are  met  via  consolidation  on  I-S/A  AMPEs  Installed  to 
replace  one  Navy  and  three  OLA  locations. 

The  population  of  AMPEs  and  I-S/A  AMPEs  through  the  Mid-Term 
and  Into  the  Far-Term  IAS  can  be  derived  from  Table  A-I.  These 
figures  are  shown  numerically  In  Table  A-II  and  graphically  In 
Figure  A*-l.  Although  NSA  AMPE  locations  are  not  listed  In  Table 
A-i,  an  analysis  of  the  26  known  locations  Indicated  that  eight 
sites  could  potentially  be  consolidated  with  other  Inter-Service/ 
Agency  AMPEs.  The  remaining  18  sites  plus  the  five  sites  that 


PROJECTED  ANPE  AND  I-S/A  AHPE  POPULATION,  BY  LOCATION  (Continued) 


could  not  b«  Identified  (Assumption  7)  yielded  23  replacement 
I -S/A  AMPEs.  These  have  been  Included  In  the  net  Increese  of 
36  replacement  I-S/A  AMPEs  shown  for  the  1985-1987  time  frame  In 
Table  A-II. 

IV.  CONCLUSIONS 

Without  the  I-S/A  AMPE  program  and  consolidation  of  AMPE  sites 
the  number  of  AMPEs  could  be  expected  to  exceed  150  by  1990  based 
on  the  projected  rate  of  growth.  The  I-S/A  AMPE  program,  with 
106  I-S/A  AMPEs  In  1990.  represents  a potential  23*  savings  In  the 


APPENOIX  B 

MID-TERM  IAS  TRAFFIC  FLOW  ANALYSIS 


1.  INTRODUCTION 


This  appendix  describes  a traffic  flow  analysis  performed  as  part 
of  the  Mid-Term  Integrated  AUTODTN  System  (IAS)  architecture  definition 
effort. 

The  primary  purpose  of  the  traffic  flow  analysis  Is  to  provide 
quantitative  results  In  support  of  the  cost  analysis  and  technical 
factors  analysis.  In  most  cases,  therefore,  the  numerical  results  of 
this  analysis  are  used  as  direct  Inputs  to  subsequent  analyses.  In 
addition,  all  phases  of  the  evaluation  process  draw  upon  qualitative 
assessments  and  insights  derived  from  this  analysis.  However,  the 
evaluation  of  alternatives  based  directly  on  traffic  flow  consider- 
ations Is  not  Intended. 

The  specific  objectives  of  this  analysis  are: 

Determine  the  probable  traffic  flow  characteristics  of  al- 
ternative architectures 

Estimate  the  size  of  communications  facilities  required  to 
support  alternative  architectures 

Estimate  the  communications  handling  capability  of  the  pos- 
tulated nodal  elements  required  to  support  each  architecture 

The  primary  purpose  of  the  Mid-Term  IAS  definition  effort  is  to 
evaluate  alternatives  and  select  a preferred  architecture  for  the  Mid- 
Term.  Therefore,  In  order  to  simplify  the  computational  effort  the 
traffic  flow  analysis  was  performed  on  a comparative  basis,  concentrating 
on  those  areas  of  traffic  flow  that  represent  a significant  difference 
among  alternatives.  Thus,  traffic  categories  which  represent  a minor 
contribution  to  total  traffic  flow,  or  which  are  common  to  all  three 
candidates,  are  not  specifically  addressed  in  the  detailed  analysis. 

The  basic  approach  to  the  traffic  flow  analysis  consists  of  the 
following  steps: 

Development  of  a baseline  network  model.  A network  configura- 
tion Is  selected,  consisting  of  the  backbone  and  portions  of 
the  access  area  which  are  architecture  dependent  (from  a 
traffic  flow  standpoint).  The  model  Is  described  by  means  of 
nominal  parameter  values  consistent  with  current  mid-term 
projections. 
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Development  of  a baseline  traffic  model.  Major  architecture* 
dependent  traffic  categories  are  identified,  and  their  flow 
through  the  network  is  described.  Nominal  values  are  speci- 
fied for  input  traffic  volumes  and  traffic  flow  parameters, 
based  upon  projected  traffic  statistics  and  an  understanding 
of  the  operating  environment.  r. 

Formulation  of  traffic  flow  equations.  For  each  traffic  cate- 
gory a set  of  expressions  is  developed  for  calculating  nodal 
and  link  traffic  flows. 

Traffic  computation.  The  various  traffic  expressions  are  in- 
corporated into  a set  of  equations  which  are  programmed  on  a 
commercial  computing  service  to  calculate  aggregate  nodal  and 
link  traffic  flows  for  each  architecture.  The  computations 
use  nominal  (baseline)  values  for  network  parameters  and  input 
traffic  volumes. 

Sensitivity  analysis.  The  impact  of  changes  in  assumptions 
and  parameter  values  on  the  traffic  results  is  explored. 

A more  detailed  description  of  the  approach  and  a summary  of  the 
results  are  presented  in  the  following  paragraphs. 

2.  ASSUMPTIONS  ANO  GROUNO  RULES 

The  traffic  flow  analysis  Is  based  upon  the  requirements  and  pro- 
jected environment  for  the  mid-term  time  frame  defined  in  Section  II  of 
the  body  of  this  report.  The  alternative  architectures  evaluated  under 
this  analysis  are  described  in  Section  III. 

a.  3aseline  Network  Model.  The  network  model  used  in  the  analy- 
sis is  defined  by  the  following  assumptions  and  guidelines: 

The  basic  PSN  backbone,  which  is  common  to  all  alternative 
architectures,  was  simplified  in  a manner  which  facilitated 
the  analysis.  However,  in  order  to  provide  some  insight  into 
the  probable  performance  of  the  eventual  IAS  network,  as  well 
as  to  promote  consistency  with  other  analyses,  the  critical 
characteristics  of  the  assumed  backbone  network  were  designed 
as  closely  as  possible  to  matcri  those  of  a representative 
backbone  network.  Specifically  the  backbone  network  model 
used  to  calculate  traffic  flows  is  shown  in  Figure  B-l.  The 
convenient  feature  of  this  model  is  Its  uniformity  - each  PSN 
Is  connected  to  four  other  PSNs  In  a regular  topology.  In  all 
major  respects  (number  of  PSNs,  average  number  of  users  per 
PSN,  average  distance  between  PSNs,  average  number  of  trunks 
per  PSN)  It  is  Identical  to  a representative  AUTOOIN  II  archi- 
tecture described  in  the  System  Performance  Specification  for 
AUTOOIN  II,  Phase  I,  January  1977  revision. 
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Each  PSN  has  associated  with  it  an  access  area,  consisting  of 
subscribers  and  network  elements.  For  the  purpose  of  this 
analysis,  the  same  uniform  configuration  (in  terms  of  sub* 
scriber  population  and  connectivity)  was  assumed  for  each 
access  area. 

The  calculation  of  traffic  flows  assumes  that: 

* subscribers  are  singly  connected  to  a nodal  element 

- I-S/A  AMPEs  are  singly  connected  to  a PSN  or  to  an  I-S/A 
AMPE(E) 

- I-S/A  AMPE(E)s  (if  any)  are  singly  connected  to  a PSN 

- CSFs  (if  any)  are  singly  connected  to  a PSN 

The  effect  of  dually  connecting  some  of  these  elements  is 
explored  In  the  sensitivity  analysis. 

The  network  model  is  a representation  of  the  projected  1988 
CONUS  configuration.  The  traffic  flow  characteristics,  how- 
ever, are  expected  to  be  relatively  constant  throughout 
the  global  system  during  the  time  frame  of  interest. 

Nominal  values  for  the  principal  network  and  subscriber  con-  m 
figuration  parameters  are  presented  in  Table  B-I  for  each  architecture. 

The  sensitivity  of  the  traffic  results  to  deviations  from  these  nominal 
values  is  discussed  later  in  the  appendix. 

b.  Baseline  Traffic  Model.  The  input  traffic  assumptions  used  in 
this  analysis  were  based  upon  the  numbers  and  types  of  users,  projected 
terminal  populations,  projected  AMPE  and  I-S/A  AMPE  populations,  and  the 
postulated  services  and  functions  that  will  be  provided  by  the  Mid-Term 
IAS.  These  issues  are  described  in  greater  detail  in  Section  II  of  the 
body  of  the  report. 

Consistent  with  the  comparative  nature  of  this  analysis,  traf- 
fic types  which  do  not  have  a significant  impact  on  the  evaluation  of 
alternatives  have  been  excluded.  The  1988  estimates  for  AUTOOIN  I and 
AUTODIN  II  average  busy  hour  traffic  (Subsection  I 1-4)  provide  the 
starting  point  in  the  identification  of  appropriate  traffic  types. 

As  a result  of  preliminary  analysis,  it  was  determined  that 
the  1988  estimates  for  Interactive  and  query/response  traffic  represent 
a relatively  minor  contribution  to  total  IAS  traffic  (less  than  5 percent), 
and  thus  were  excluded  from  the  analysis.  It  was  also  determined  that 
the  flow  of  AUTODIN  II  bulk  data  traffic  is  virtually  identical  in  the 
three  alternative  architectures,  and,  therefore,  not  necessary  for  a 
comparative  evaluation.  (Because  of  its  substantial  volume,  however, 
bulk  traffic  was  factored  into  the  subsequent  analysis  of  transmission 
cost. ) 
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TABLE  B-I.  BASELINE  NETWORK  PARAMETERS 


ARCHITECTURE 

PARAMETER 

1 

II 

III 

NUMBER  OF  PSN* 

8 

8 

8 

NUMBER  OF  CSFs 

1-8 

0 

1-8 

NUMBER  OF  l-S/A  AMPE(E)t 

0 

1-8 

• 

1-8 

NUMBER  OF  l-S/A  AMPE*(,) 

70 

62-68^ 

«MB® 

NUMBER  OF  TERMINALS 

1200  DIN  1 

1900  OIN  II 

1200  OIN  1 

1800  DIN  II 

1200  OIN  1 
1800  DIN  II 

FRACTION  OF  l-S/A  AMPE* 
DIRECTLY  CONNECTED 

TO  A PSN 

30% 

30% 

30% 

NUMBER  OF  PSN-PSN  LINKS 
INCIDENT  ON  A PSN 


4 


4 


4 


Consequently,  the  traffic  flow  analysis  focused  on  narrative/ 
record  (N/R)  traffic  from  both  AUTODIN  I- type  and  AUTODIN  I I- type  sub- 
scribers. For  the  purpose  of  the  analysis,  an  AUTODIN  I- type  subscriber 
is  defined  as  a message  oriented  user  with  terminal  equipment  (including 
AMPEs)  which  will  support  only  AUTOOIN  I type  operation.  An  AUTODIN  II- 
type  subscriber  is  defined  as  an  ADP  oriented  user  with  terminal  equip- 
ment that  will  support  AUTODIN  II  type  operation.  These  definitions 
(introduced  in  Subsection  III-2-f  of  the  report)  are  used  only  for  the 
purpose  of  modeling  the  existing  subscriber  characteristics  related  to 
traffic  flow.  As  the  IAS  evolves  through  the  mid-term,  it  is  antici- 
pated that  such  distinctions  will  no  longer  be  required. 

The  IAS  traffic  is  also  classified  according  to  its  destina- 
tion - local  or  remote.  For  the  purpose  of  this  analysis,  local  is  de- 
fined to  mean  "served  by  the  same  PSN".  The  baseline  traffic  model 
assumes  that  25  percent  of  the  input  traffic  is  sent  to  local  subscri- 
bers. 


In  addition  to  subscriber  type  and  traffic  destination,  the 
services  provided  by  the  network  are  important  factors  in  the  charac- 
terization of  traffic  flow  among  nodal  elements.  Consideration  of  the 
Mid-Term  IAS  services  and  functions  led  to  the  definition  of  six  basic 
categories  of  narrative/ record  traffic,  selected  for  use  in  the  traffic 
flow  analysis: 

Single  Address  Messages 
Multiple  Address  Messages 
Teleconferencing 
. Gateway 
Mailbox 

AUTODIN  II  traffic  requiring  no  service  element  support 

Average  input  traffic  values  for  each  category  are  presented  in  Table 
B-II,  for  AUTODIN  I and  AUTOOIN  II  subscribers.  The  modeling  of  these 
categories  is  discussed  in  the  following  section. 

Additional  assumptions  which  characterize  the  baseline  traffic 
model  are  the  following: 

The  nodal  (or  network)  elements  of  interest  in  this  analysis 
are  the  Packet  Switched  Node  (PSN),  the  Central  Service  Facili- 
ty (CSF),  and  the  Enhanced  Inter-Service/Agency  AMPE  (I-S/A 
AMPE(E)).  Since  the  basic  I-S/A  AMPE  is  common  to  all  three 
alternative  architectures,  it  was  treated  as  a source  of  traf- 
fic input  for  the  purpose  of  this  analysis.  The  CSF  and  the 
I-S/A  AMPE(E)  are  the  candidate  service  elements  for  the  mid- 
term IAS. 
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y TABLE  B-II.  AVERAGE  1988  INPUT  TRAFFIC  ESTIMATES  (BUSY  HOUR) 

r 


AUTODIN  1 

AUTOOIN  II 

TRAFFIC  CATEGORY 

Input  Rati 
IKbpt] 

Frwtion 
of  Total 

Input  Rat* 
(Kbps] 

Fraction 
of  Total 

• SINGLE-ADDRESS  MESSAGES 

213.8 

64% 

18.1 

15% 

• MULTIPLE-ADDRESS  MESSAGES 

70.1 

21% 

6.1 

5% 

• TELECONFERENCING 

1B.7 

5% 

12.1 

10% 

• GATEWAY 

18.7 

6% 

6.1 

5% 

• MAILBOX 

16.7 

6% 

18.1 

16% 

• AUTODIN  II  TRAFFIC  REQUIRING 

NO  SERVICE  ELEMENT  SUPPORT 

- 

0% 

60.5 

50% 

TOTAL 

334.0 

100% 

121.0 

100% 

The  links  of  interest  in  the  traffic  flow  calculations  are: 

PSN  - PSN 

- PSN  - CSF  (Architecture  I and  III) 

PSN  - I-S/A  AMPE(E)  (Architecture  II  and  III) 

„ PSN  ~ I-S/A  AMPE 

I-S/A  AMPE(E)  - I-S/A  AMPE  (Architecture  II  and  III) 

In  order  to  simplify  the  traffic  calculations  certain  "uni- 
formity" assumptions  have  been  made.  In  particular,  the  PSNs 
are  modeled  identically,  regardless  of  how  many  CSFs  and  I-S/A 
AMPE(E)s  the  network  actually  contains  (unless,  of  course, 
there  are  none).  By  the  same  concept,  traffic  in  the  backbone 
is  assumed  to  be  distributed  uniformly  over  all  PSN-PSN  links. 
These  simplifying  assumptions  should  not  diminish  the  signifi- 
cance of  the  results,  since  the  analysis  concentrates  on 
average  (i.e. , global)  traffic  flow  behavior  in  the  network. 

The  fraction  of  traffic  generated  by  subscribers  terminated  on 
I-S/A  AMPEs  assumed  a nominal  value  of  87.2  percent  (average 
over  all  six  traffic  categories  and  subscriber  types). 

Certain  traffic  categories  involve  the  delivery  of  a message 
or  transaction  to  multiple  destinations.  This  "traffic  ex- 
pansion" is  accomplished  at  a service  element.  The  nominal 
average  expansion  factors  used  in  the  analysis  are: 

for  Multiple  Address  Message  Transfer:  7 

- for  Teleconferencing:  2.5 

- for  Mailbox:  2.5 

All  traffic  flows  in  this  analysis  are  based  on  1988  projec- 
tions for  busy  hour  traffic. 

The  sensitivity  of  the  traffic  flow  results  to  changes  in  the 
baseline  traffic  parameters  is  addressed  in  the  following  section. 

3.  TRAFFIC  CALCULATIONS 

The  baseline  network  and  traffic  models  described  above  constitute 
the  basis  for  the  formulation  of  traffic  flow  equations.  These  equa- 
tions describe,  for  each  alternative  architecture,  the  movement  of  data 
from  source  to  destination  via  intermediate  links  and  nodal  elements. 

The  flow  of  traffic  is  a function  of:  the  type  of  traffic  (and  hence 
the  services/functions  required  from  nodal  elements);  the  type  of  sub- 
scriber at  the  source;  and  the  type  and  location  of  the  subscriber  at 
the  destination. 
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a.  Nodal  Element  Traffic.  Source- to-desti nation  flows  have  been 
postulated  for  each  traffic  category  In  order  to  develop  the  necessary 
equations.  These  flows  are  not  intended  to  be  exact  representations  of 
IAS  traffic.  Rather,  they  are  simplifications,  defined  for  the  purpose 
of  this  analysis,  which  model  conservative  or  "worst-case"  traffic 
patterns.  Their  purpose  is  to  illustrate  the  basic  behavior  of  traffic 
in  the  network.  A brief  description  of  the  modeling  of  the  six  defined 
traffic  categories  (introduced  in  Table  B-II)  follows. 

Single-Address  Message  Traffic  - in  general,  this  is  modeled 
as  single- address  traffic  that  travels  from  source  to  desti- 
nation via  an  Intermediate  processing  node.  For  AUTOOIN  I- 
type  subscribers  directly  connected  to  an  I-S/A  AMPE  the 
intermediate  processing  Is  assumed  to  occur  at  the  I-S/A  AMPE. 
For  all  other  subscriber  types  and  connections,  traffic  is 
assumed  to  flow  to  the  nearest  service  element  (CSF  In  Al- 
ternative I,  I-S/A  AMPE(E)  In  Alternatives  II  and  III)  before 
proceeding  to  its  destination. 

Multiple-Address  Message  Traffic  - modeled  as  multiple-address 
traffic  with  an  average  of  seven  addressees  (baseline  value). 
The  model  assumes  that  this  traffic  travels  from  its  source  to 
the  nearest  service  element  (CSF  in  Alternative  I,  I-S/A 
AMPE(E)  In  Alternatives  II  and  III),  from  which  the  message  is 
transmitted  seven  times  to  different  destinations.  This 
simplified  model  does  not  portray  the  actual  flow  of  Multiple- 
Address  traffic  In  the  AUTOOIN  system.  However,  the  disparity 
between  the  model  and  the  actual  flow  can  be  simply  translated 
Into  a difference  In  the  number  of  addressees.  The  sensitivity 
analysis  explores  the  variation  in  this  parameter,  and  indi- 
cates that  the  comparative  results  among  alternatives  are 
Insensitive  to  the  number  of  addressees. 

Teleconferencing  Traffic  - modeled  In  a similar  manner  to 
Multiple-Address  traffic,  but  with  an  average  of  2.5  addresses 
(baseline  value).  The  model  assumes  a flow  from  source  to  the 
nearest  service  element  (CSF  In  Alternatives  I and  III,  I-S/A 
AMPE(E)  in  Alternative  II),  from  which  multiple  copies  are 
sent  to  their  destinations. 

Gateway  Traffic  - modeled  as  single-address  traffic  that  flows 
from  an  IAS  source  to  the  nearest  service  element  (CSF  in 
Alternatives  I and  III,  I-S/A  AMPE(E)  in  Alternative  II),  and 
then  to  an  external  destination;  or  from  an  external  source  to 
the  nearest  service  element  and  then  to  an  IAS  destination.  It 
Is  assumed  that  an  equal  amount  of  traffic  flows  Into  and  out 
of  the  network. 
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Mailbox  Traffic  - modal  ad  as  multi  pi e- address  traffic  that 
travels  (as  a single  copy)  from  tha  sourca  to  tha  naarast  ser- 
vica  alamant  (CSF  in  Alternative  I,  I-S/A  AMPE(E)  In  Alterna- 
tivas  II  and  III),  from  which  it  is  transmitted  to  M other 
service  elements  (M  is  a function  of  tha  number  of  service 
elements,  tha  average  number  of  addressees,  and  whether  the 
destinations  are  local  or  remote).  On  the  average,  a total  of 
2.5  copies  of  the  massage  (baseline  value)  are  then  trans- 
mitted  from  the  service  elements  to  the  appropriate  destina- 
tions. 

AUTODIN  II  Traffic  requiring  no  service  element  support  - 
modeled  as  single-address  traffic  transmitted  from  one AUTQOIN 
II  subscriber  to  another,  without  the  need  for  intermediate 
processing  at  a service  element. 

The  basic  nodal  traffic  flows  for  the  three  IAS  architectures 
are  defined  by  the  following  rules: 

the  PSN  Input  consists  of  traffic  from  CSFs  (In  Alternatives  I 
and  III),  I-S/A  AMPE(E)s  (Alternatives  II  and  III),  other 
PSNs,  and  Its  community  of  users  ( 1 . e. , subscribers  connected 
directly  to  the  PSN  or  Indirectly  via  an  AMPE  or  I-S/A  AMPE). 

the  CSF  (Alternatives  I and  III)  exchanges  traffic  only  with 
the  PSN  to  which  it  is  connected  and  with  external  subscribers 
via  a gateway. 

an  I-S/A  AMPE(E)  (Alternatives  II  and  III)  exchanges  traffic 
with  the  PSN  to  which  It  is  connected,  its  own  community  of 
users  (connected  directly  or  via  an  AMPE  or  I-S/A  AMPE),  and 
with  external  subscribers  via  a gateway. 

The  five  nodal  traffic  flows  of  Interest  are: 

PSN.  - the  average  PSN  Input  traffic  (equal  to  the  PSN  output 
1 traffic) 

CSFj  - the  average  CSF  Input  traffic 

CSF  - the  average  CSF  output  traffic  (greater  than  CSF.  due 
to  the  expansion  associated  with  some  traffic  cate- 
gories) 

Ej  - the  average  I-S/A  AMPE(E)  Input  traffic 

E - the  average  I-S/A  AMPE(E)  output  traffic  (greater  than 
0 E.  due  to  the  expansion  associated  with  some  traffic 
categories). 


Sine*  six  distinct  categories  of  traffic  contribute  to  each  of 
these  five  flows,  a total  of  thirty  equations  are  required  to  describe 
traffic  flows  through  the  three  types  of  network  elements.  These  equa- 
tions are  functions  of  several  parameters,  relating  to: 

the  alternative  architecture  (e.g. , number  and  type  of  service 
elements,  distribution  of  functions/services  among  network 
elements,  etc.) 

Input  traffic  (rates  specified  in  the  baseline  traffic  model) 

subscriber  type  (l.e. , AUTOOIN  I or  II,  local  or  remote) 

traffic  category  (e.g.,  traffic  expansion  factor,  source-to- 
destlnatlon  paths,  functions/services  required,  etc.) 

network  topology  and  connectivity  (e.g.,  average  number  of 
PSNs  between  source  and  destination,  average  distance  between 
a source  and  the  nearest  service  element,  etc.) 

Applying  the  stated  assumptions  and  ground  rules,  and  using  the  basic 
traffic  equations,  the  nodal  element  flows  are  computed  for  each  traffic 
component.  The  aggregate  traffic  flow  through  the  network  elements  of 
Interest  was  then  calculated  by  adding  the  various  contributions. 

Due  to  the  number  of  computations  involved,  computer  support 
was  required  for  the  calculation  of  traffic  flows  and  to  provide  com- 
puter-generated plots  of  the  key  network  output  parameters,  as  a func- 
tion of  architecture  and  number  of  service  elements.  The  most  illus- 
trative of  these  plots  are  presented  and  discussed  in  the  following 
paragraphs. 

Figure  B-2  shows  the  average  PSN  throughput  (i.e. , Input  plus 
output)  obtained  by  taking  the  PSN  throughput  for  the  entire  network  and 
dividing  by  the  number  of  PSNs  (eight).  As  In  all  the  plots  presented 
herein,  a square  is  used  for  Architecture  I data  points,  a triangle  for 
Architecture  II,  and  a diamond  for  Architecture  III.  For  Architecture 
I,  the  X-axis  represents  the  number  of  CSFs,  while  for  Architectures  II 
and  III,  the  X-axis  Indicates  the  number  of  I-S/A  AMPE(E)s.  For  Archi- 
tecture III,  the  number  of  CSFs  Is  varied  from  1 to  8,  resulting  In  a 
family  of  8 curves.  The  Y-axis  Indicates  the  throughput  traffic  In  busy 
hour  kb/s.  Most  of  the  curves  are  plotted  on  identical  scales  to  facili- 
tate comparison. 

The  most  conspicuous  feature  of  Figure  8-2  Is  the  relatively 
small  variation  with  architecture  and  number  of  service  elements.  Fig- 
ure 8-3  shows  the  same  curves  on  an  expanded  scale.  Note  that  all  of 
the  curves  exhibit  the  same  gross  features:  a sharp  decrease  In  PSN 
traffic  In  going  from  1 to  2 service  elements,  little  decrease  In  going 


fro*  2 to  3 service  elements,  and  a roughly  linear  decrease  thereafter. 
All  of  the  Architecture  III  curves  have  the  same  slope,  which  Is  Inter- 
Mediate  between  the  slopes  of  the  Architecture  I and  II  curves.  As 
expected,  Architectures  II  and  III  require  less  PSN  capacity  than  Archi- 
tecture I,  prlearlly  because  of  the  ability  of  the  I-S/A  AMPE(E)  to 
switch  traffic  to  local  users  without  using  the  backbone  (this  type  of 
traffic  comprises  about  12  percent  of  the  total  network  traffic). 

Figure  EM  Illustrates  the  average  throughput  per  service 
element.  Note  that  Architecture  I requires  significantly  lower  service 
element  capacity  than  Architecture  II  for  an  equal  number  of  service 
elements.  The  primary  reason  for  this  Is  the  large  amount  of  traffic 
that  passes  through  I-S/A  AMPE(E)s  on  the  way  from  source  to  destination 
(Including  traffic  which  requires  no  service).  Although  Architecture 
III  appears  to>be  better  than  Architecture  I In  many  cases,  It  should  be  • 
remembered  that  the  average  service  element  throughput  Is  greatly  lowered 
by  the  presence  of  from  1 to  8 CSFs  In  addition  to  the  number  of  I-S/A 
AHPE(E)s  Indicated  by  the  X-axis. 

For  a somewhat  fairer  comparison,  Figure  B-5  shows  the  total 
(aggregate)  service  element  throughput  as  a function  of  the  number  of 
CSFs  or  I-S/A  AMPE(E)s.  There  Is  only  one  curve  for  Architecture  III, 
because  the  total  service  element  throughput  Is  Independent  of  the  num- 
ber of  CSFs  for  this  architecture  (this  Is  not  true  for  Architecture  I 
because  In  that  architecture  the  mailbox  function  Is  performed  In  the 
CSF,  and  the  number  of  Intermediate  messages  required  Increases  with  the 
number  of  CSFs). 

Figure  B-6  presents  a final  comparison  of  total  PSN  throughput 
for  the  three  architectures.  In  this  figure,  the  X-axis  presents  the 
total  number  of  service  elements  (number  of  CSFs  plus  number  of  I-S/A 
AMPE(E)s  for  Architecture  III).  The  one  curve  shown  for  Architecture 
III  Is  based  on  the  combinations  of  CSFs  and  I-S/A  AMPE(E)s  that  mini- 
mize the  total  PSN  throughput.  This  optimized  version  of  Architecture 
III  exhibits  throughputs  slightly  lower  than  Architecture  II  but  some- 
what higher  than  Architecture  I.  However,  the  particular  combinations 
of  I-S/A  AMP£(£)s  and  CSFs  that  minimize  the  total  PSN  throughput  may  be 
sub-optimal  In  other  respects.  For  example,  in  the  case  of  8 service 
elements,  the  lowest  throughput  for  Architecture  III  occurs  with  6 CSFs 
and  only  2 I-S/A  AMPE(E)s,  a combination  that  could  exhibit  poor  sur- 
vivability and  less  than  optimal  response  time. 

The  results  of  the  nodal  flow  analysis  were  used  In  Appendix  C 
to  determine,  for  each  architecture,  the  communications  load  on  the  net- 
work elements.  This  configuration  was  helpful  In  sizing  the  elements 
and  estimating  personnel  requirements. 
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Figure  8-4.  Mean  Service  Element  Throughput 


Total  PSN  Throughput  vs.  Total  Number  of 
Service  Elements  (Architecture  III  Optimized) 
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b.  Link  Traffic.  Once  the  nodal  traffic  flows  are  computed,  as 
described  In  the  preceding  section,  It  is  possible  to  calculate  the 
average  traffic  flow  on  all  major  communication  links  between  the  nodal 
elements.  This  is  done  by  applying  conservation  of  traffic  flow  at  each 
network  element  to  obtain  a set  of  equations. * (For  the  purpose  of  this 
analysis  basic  network  element  structures  were  defined  which  modeled  the 
elements  and  the  links  between  them.)  The  equations,  based  on  assump- 
tions similar  to  those  used  in  calculating  nodal  flows,  were  solved  to 
obtain  the  link  flows  of  interest. 

Again,  because  of  the  number  of  computations  involved,  com* 
puter  support  was  used  in  calculating  traffic  flows.  The  link  traffic 
analysis  produced  a series  of  circuit  traffic  values  for  each  architec- 
ture as  a function  of  the  number  of  service  elements.  These  results 
provide  a major  input  into  the  transmission  cost  analysis  (Appendix  C), 

c.  Sensitivity  Analysis.  In  order  to  ascertain  the  sensitivity 
of  the  results  and  conclusions  of  this  study  to  variations  in  the  input 
parameters,  a number  of  computer  runs  were  made  in  which  the  baseline 
parameter  values  were  modified,  one  at  a time.  For  each  parameter 
varied,  the  resultant  average  change  in  the  output  parameters  was  calcu- 
lated. The  output  parameters  of  interest  are  the  average  PSN  throughput 
and  the  average  service  element  throughput. 

Two  aspects  of  sensitivity  are  of  interest  to  the  study. 

First,  does  a large  variation  in  the  input  parameter  of  interest  have  a 
large  effect  on  the  output  parameters?  Second,  and  more  Importantly, 
does  the  change  have  approximately  the  same  effect  with  each  archi- 
tecture? The  second  question  is  more  important  to  this  study  because 
architecture  dependent  variations  could  result  in  changes  in  the  con- 
clusions if  Input  parameter  values  change  significantly. 

The  results  of  the  sensitivity  analysis  are  summarized  in 
Table  B-III.  The  table  shows  that  the  results  are  rather  insensitive  to 
the  number  of  PSNs  and  the  PSN  connectivity.  Furthermore,  the  varia- 
tions that  do  occur  are  fairly  consistent  from  one  architecture  to 
another  so  that  these  parameters  do  not  affect  the  conclusions. 

Two  parameters  that  describe  the  configuration  of  subscribers 
were  examined:  the  fraction  of  traffic  generated  by  I-S/A  AMPE- termi- 
nated subscribers,  and  the  fraction  of  I-S/A  AMPEs  directly  connected  to 
PSNs.  Although  the  output  parameters  are  not  extremely  sensitive  to 
these  input  parameters,  significant  changes  in  the  baseline  values  could 
conceivably  affect  some  of  the  conclusions.  For  example,  the  service 


"the  algebraic  sum  of  traffic  flows  entering  and  leaving  a network 
element  (taking  into  account  traffic  expansion  at  some  elements)  is 
equal  to  zero. 


8-18 


t 


element  throughput  decreases  when  the  first  of  these  parameters  Increase 
for  Architecture  I;  the  reverse  Is  true  for  the  other  two  alternatives. 
Thus,  If  fewer  subscribers  are  connected  to  I -S/A  AMPEs,  the  advantage 
In  lower  service  element  throughput  enjoyed  by  Architecture  I will  begin 
to  shrink.  At  the  same  time,  the  PSN  throughput  advantage  of  Architec- 
ture II  and  III  also  shrinks. 

A very  similar  situation  exists  with  respect  to  the  fraction 
of  I-S/A  AMPEs  directly  connected  to  PSNs.  As  this  parameter  increases, 
the  difference  in  service  element  traffic  among  architectures  decreases. 
However,  the  advantage  In  PSN  throughput  exhibited  by  Architectures  II 
and  III  shrinks  concomitantly.  In  fact.  If  the  fraction  Is  unity, 
Architectures  I and  II  become  Identical,  because  there  Is  no  longer  any 
difference  between  CSFs  and  I-S/A  AMPE(E)s.  As  a result,  we  can  con- 
clude that  connecting  a smaller  portion  of  the  subscribers  to  I-S/A 
AMPE(E)s  can  be  effected  either  by  connecting  more  subscribers  directly 
to  PSNs  or  by  connecting  fewer  I-S/A  AMPEs  to  I-S/A  AMPE(E)s.  In  either 
case,  the  differences  between  the  three  architectures  may  be  diminished 
considerably. 

Table  B-III  shows  that  the  results  are  fairly  insensitive  to 
the  fraction  of  local  vs.  remote  traffic  and  the  percentage  of  traffic 
requiring  new  functions.  Again,  the  variations  that  do  occur  are  quite 
consistent  from  one  architecture  to  another. 

Finally,  the  sensitivity  analysis  Indicates  that  the  results 
are  fairly  sensitive  to  the  average  number  of  addressees  for  traffic 
requiring  AUTODIN  I functions  (l.e.  Multiple-Address  Traffic)  but  very 
insensitive  to  the  expansion  factors  for  Mailbox  and  Teleconferencing. 
This  Is  to  be  expected  since  a much  larger  percentage  of  traffic  re- 
quires AUTODIN  I functions  than  requires  the  Mailbox  and  Teleconfer- 
encing functions.  Nevertheless,  the  variations  induced  in  the  output 
parameters  are  remarkably  consistent  from  architecture  to  architecture, 
so  that  the  conclusions  are  unaffected  by  these  two  Input  parameters. 

The  sensitivity  of  comparative  link  traffic  results  is  ex- 
plored In  the  analysis  of  communications  costs  (Appendix  C). 

d.  Effect  of  Dual  Connected  I-S/A  AMPEs  on  Network  Traffic. 

In  all  of  the  analysis  presented  thus  far,  it  was  assumed  that  each  I- 
S/A  AMPE  was  connected  either  directly  to  a PSN  or  to  an  I-S/A  AMPE(E) . 
As  a consequence,  traffic  flowing  to  or  from  an  I-S/A  AMPE  connected 
through  an  I-S/A  AMPE(E)  had  to  flow  through  the  I-S/A  AMPE(E)  whether 
or  not  It  required  I-S/A  AMPE(E)  functions.  This  situation  has  an 
adverse  Impact  on  network  survivability  and  on  the  cost  of  an  I-S/A 
AMPE(E). 
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On*  way  to  alleviate  this  problem  Is  to  dually  connect  all  I* 
S/A  AMPEs  at  nodes  possessing  an  I-S/A  AMPE(E)  by  connecting  each  I-S/A 
AMPE  to  Its  local  PSN  and  to  Its  local  I-S/A  AMPE(E).  This  procedure 
reduces  the  I-S/A  AMPE(E)  traffic  flows  to  a level  equal  to  the  CSF 
traffic  flows  of  Architecture  I.  At  the  same  time,  the  PSN  throughput 
decreases  slightly  because  many  I-S/A  AMPEs  that  previously  had  to  rout* 
traffic  through  a PSN  to  get  to  the  local  I-S/A  AMPE(E),  can  now  rout* 
traffic  directly  to  the  I-S/A  AMPE(E). 

The  network  flow  calculations  for  Architecture  II  were  revised 
based  on  the  dual  connection  assumption  described  above.  Traffic  flows 
were  recalculated  with  the  number  of  I-S/A  AMPE(E)s  varied  from  one  to 
eight.  The  salient  results  were  as  follows: 

The  I-S/A  AHPE(E)  throughput  was  greatly  reduced 

- I-S/A  AMPE(E)  Input  traffic  decreased  by  15  to  70  percent 

- I-S/A  AHPE(E)  output  traffic  decreased  by  5 to  44  percent 

The  PSN  throughput  decreased  very  slightly  (a  maximum  of  7 
percent 

Traffic  flows  In  the  access  area  were  reduced  by  as  much  as  19 
percent  and  significantly  redistributed. 

All  three  of  these  factors  should  have  some  Impact  on  the  cost 
and  survivability  of  the  IAS  network. 

4.  CONCLUSIONS 

It  should  be  remembered  that  the  purpose  of  the  traffic  flow  analy- 
sis Is  to  provide  quantitative  Inputs  to  the  cost  analysis  and  technical 
factors  evaluation  process.  Therefore,  conclusions  regarding  the  com- 
parative desirability  of  the  alternatives  as  a result  of  traffic  flow 
considerations  are  not  appropriate.  However,  In  the  process  of  per- 
forming this  analysis,  several  significant  findings  were  obtained: 

PSN  traffic  loading  Is  relatively  Insensitive  to  architecture 
choice  and  will  be  determined  principally  by  the  number  of 
service  elements  to  be  supported 

the  dual  connection  of  I-S/A  AMPE  nodes  to  a PSN  and  an  I-S/A 
AMPE(E)  results  In  a significant  Improvement  of  traffic  dis- 
tribution as  well  as  element  throughput  requirements 

all  three  architecture  alternatives  are  feasible. 

As  a result  of  this  analysis,  it  is  recommended  that  architecture  Al- 
ternatives II  and  III  make  us*  of  dual  connection  to  a PSN  and  an  I-S/A 
AMPE(E)  as  the  preferred  connection  policy  for  the  I-S/A  AMPE. 
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COST  ANALYSIS 
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1 . INTRODUCTION 

This  appendix  describes  the  major  aspects  and  results  of  a com* 
paratlve  cost  analysis  performed  In  support  of  the  mid-term  IAS  arch- 
itecture definition  effort.  The  analysis  focused  on  two  objectives: 
comparative  evaluation  of  candidate  mid-term  architectures,  and  com- 
parison between  the  preferred  mid-term  alternative  and  the  baseline 
architecture  projected  to  the  mid-term. 

A few  preliminary  observations  are  In  order.  First,  the  analysis 
of  alternatives  Is  comparative.  Therefore,  costs  common  to  all  of 
the  alternatives  have  been  excluded  In  order  to  simplify  the  analysis. 
Secondly  the  analysis  seeks  to  select  a least-cost  alternative  with- 
out resorting  to  an  exhaustive  life-cycle  cost  effort  which  would  re- 
quire detailed  Information  on  Implementation  strategy.  Therefore, 
the  analysis  Is  limited  to  the  level  of  detail  necessary  to  the  Identi- 
fication of  trends  and  projections  which  provide  an  adequate  basis  for 
relative  cost  comparison  and  ranking  among  alternatives. 

The  basic  approach  to  the  cost  analysis  consists  of  the  follow- 
ing steps: 


Identification  and  analysis  of  major  cost  elements.  From 
a complete  list  of  elements,  only  those  found  to  be  depen- 
dent upon  network  architecture  have  been  retained.  These 
are: 

- Transmission  Cost 

- Nodal  Element  Acquisition  Cost 

- Nodal  Element  Operation  and  Maintenance  Cost. 

Identification  of  architecture  dependent  cost  factors  with- 
in each  cost  element.  Again,  costs  which  are  common  to  all 
three  architectures  have  been  discarded. 

Development  of  cost  estimating  relationships  or  costing 
methods  for  each  cost  factor.  In  cases  where  a closed 
form  expression  Is  not  applicable  or  Is  difficult  to  ob- 
tain, a costing  method  has  been  developed  which  produces  the 
cost  value  for  given  parameter  values. 

Evaluation  of  architecture  dependent  cost  factors.  The 
cost  factors  are  evaluated  using  nominal  parameter  values. 
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. Sensitivity  analysis.  Parameters  and  assumptions  are  varied 
and  the  Impact  on  cost  Is  assessed.  Those  which  drive  the 
total  cost  are  Identified. 

. Accumulation  of  cost  factors  and  ranking  of  alternatives. 

The  cost  factors  within  each  major  cost  element  are  eval- 
uated and  aggregated  Into  a total  element  cost.  The  total 
cost,  together  with  sensitivity  and  other  considerations. 

Is  used  to  rank  the  alternatives. 

. Overall  cost  ranking  of  alternatives.  The  results  associ- 
ated with  each  major  cost  element  are  combined  Into  a final 
ranking.  The  relative  weights  of  the  cost  elements  are 
factored  Into  this  evaluation  process. 

Additional  general  assumptions  and  ground  rules  that  support 
the  cost  analysis  are  presented  below. 

. The  number  of  subscriber  terminals  and  host  computers  In 
the  system  Is  Independent  of  the  architectural  alternative. 
This  cost  component  has  been  excluded  from  the  comparative 
analysis. 

. For  simplicity,  the  cost  Impact  of  certain  architectural 
Issues  was  not  factored  Into  the  analysis.  Prime  examples 
are  securl ty  and  system  management  and  control . These 
Issues  were,  however,  addressed  under  various  technical 
criteria  (see  Appendix  D). 

. Within  each  major  cost  element  the  analysis  focused  on 

those  cost  factors  which  contribute  the  most  to  total  cost. 
Items  subordinate  to  these  primary  factors  will,  In  general, 
follow  the  primary  factors  and  only  Increase  the  magnitude 
of  any  comparative  cost  difference. 

. The  cost  calculations  are  expressed  In  current  dollars. 

The  uncertainty  associated  with  the  mid-term  Implementation 
strategy,  as  well  as  the  requirement  for  comparative  re- 
sults, made  the  added  complexity  of  price  level  and  dis- 
count factors  unjustifiable. 

The  cost  analysis  presented  In  this  appendix  assumes  a typical 
1988  network  configuration  for  each  alternative  architecture  for  the 
purpose  of  computing  nominal  costs.  Based  on  these  mid-term  con- 
figurations, a projected  network  element  Inventory  was  developed. 

This  Inventory  took  Into  account  both  geographic  and  survivability 
considerations  In  order  to  determine  the  probable  minimum  number  of 
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each  type  of  element  required  for  each  alternative.  Typical  CONUS 
and  overseas  configurations  for  the  1988  alternatives,  as  well  as 
the  expected  1983  baseline,  are  presented  In  Table  C-I. 
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2.  COMPARISON  AMONG  ALTERNATIVE  MIO-TERM  ARCHITECTURES 

a.  Transmission  Cost.  Following  the  approach  outlined  above, 
comparative  transmission  costs  for  the  three  alternatives  were  com- 
puted. This  Involved  sizing  and  costing  various  links  In  the  network, 
using  the  backbone  and  access  area  topologies  specified  In  the  traffic 
:.adel  (described  In  a separate  app^dlx). 

The  following  assumptions  and  guidelines  were  used  In 
analyzing  transmission  costs: 

Link  traffic  estimates  were  used  In  sizing  communication 
lines.  The  analysis  was  limited  to  narrative/record  (N/R) 
and  bulk  data  transfer  (BOT)  traffic.  Estimates  of  Inter- 
active and  query/ response  requirements  show  these  to 
represent  a relatively  minor  contribution  to  total  AUTODIN 
traffic  (less  than  5%).  Narrative/ record  estimates  were 
furnished  by  the  traffic  analysis  computer  model,  which  takes 
Into  account  the  various  subscriber  types,  their  distribution, 
connectivity  and  service  requirements.  Bulk  data  transfer 
estimates  were  computed  In  a similar  manner.  This  traffic 
consists  of  termlnal-to-computer  and  computer-to  computer 
transfers,  and  requires  no  services  from  a CSF  or  I-S/A  AMPE(E). 

Consistent  with  the  comparative  character  of  the  analysis, 
those  links  carrying  the  same  traffic  In  all  three  architec- 
tures were  neglected.  For  the  remaining  links,  however,  the 
total  traffic  (architecture  dependent  and  Independent  compon- 
ents) was  used  for  sizing.  This  last  category  Includes  PSN- 
to-PSN  and  PSN-to-CSF  links  In  the  backbone,  as  well  as 
I-S/A  AMPE(E)-to-PSN  and  I-S/A  AMPE-to-PSN  links  In  the  access 
area. 

Cost  calculations  were  based  on  estimates  of  1988  average 
busy  hour  traffic,  assuming  1988  link  configurations. 

Transmission  facility  lease  costs  were  calculated  based  on 
available  coomon  carrier  bulk  tariffs  for  both  vo1ce-g~ade 
and  wideband  circuits.  Rates  (In  current  dollars)  Include 
mileage  dependent  and  service  (fixed)  charges  as  follows: 
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TABLE  C-I.  TYPICAL  CONFIGURATIONS 


56  Kbps  trunks  In  the  backbone  - $6. 72/mi /mo 

$920/mo 

300-9600  baud  lines  in  the  access  area  - $0. 56/mi /mo 

$86. 60/mo. 

(Source:  Defense  Commercial  Communications  Office.)  All 
lines  are  full-duplex,  with  capacity  determined  by  the 
largest  of  the  two  unidirectional  flows. 

For  simplicity,  modem  and  multiplexer  costs  were  assumed  to 
be  architecture  Independent,  and  were  excluded  from  the 
calculations.  In  addition,  no  attempt  was  made  to  optimize 
circuit  selection  by  mixing  available  offerings  (the  Impact 
would  be  to  lower  all  costs  fairly  evenly). 

A nominal  line  utilization  factor  of  50%  was  used  In  this 
study,  to  account  for  overhead,  traffic  growth,  and  delay 
performance  requirements.  The  effect  of  varying  this  value 
Is  discussed  later,  as  a sensitivity  Issue. 

All  elements  were  assumed  to  be  single-homed  for  simplicity. 
The  Impact  of  dual  homing  on  transmission  cost  Is  addressed 
later. 

The  transmission  cost  study  Is  restricted  to  CONUS  configure 
tlons.  However,  It  Is  likely  that  overseas  alternatives 
will  either  be  very  similar  (l.e.,  architecture  Independent) 
or  Implemented  according  to  the  corresponding  CONUS  strategy 
In  which  case  the  same  comparative  results  (ranking)  should 
hold. 


Transmission  cost  Is  broken  down  Into  two  major  components: 
backbone  cost  (Cm3)  and  access  area  cost  (Caa)*  A more  detailed 
classification  of  these  costs  is  presented  In  Figure  C-l.  In  order 
to  exclude  from  the  analysis  costs  common  to  all  three  alternatives, 
a device  M (which  could  be  thought  of  as  "virtual  multiplexer"  or 
concentration  point)  and  costs  Cp^  and  C^t  were  Introduced.  Accord- 
ing to  this  scheme,  Com  Incorporates  the  architecture  dependent  portion 
of  PSN-to-I-S/A  AMPE  line  cost,  while  Cmi  accounts  for  the  architecture 
Independent  portion.  It  should  be  noted  that  for  a given  alternative, 
one  or  more  of  the  elements  In  Figure  C-1  may  equal  zero. 

Transmission  costs  used  In  the  comparative  analysis  are  the 
backbone  cost  (Cgg)  and  the  architecture  dependent  portion  of  the 
access  area  costs  (Caa(V))*  The  cost  expressions  used  In  the  com- 
putations are  shown  In  Figure  C-2. 


Total  Transmission  Cost 


Backbone  Cost 


Architecture  Independent  Segment  of  Access  Area  Cost 
Architecture  Dependent  Segment  of  Access  Area  Cost 
Cost  of  PSN-PSN  Links 


Cost  of  PSN-CSF  Links 


Access  Line  Cost  for  PSN-Termlnated  Subscribers 


Access  Line  Cost  for  I-S/A  AMPE  - Terminated  Subscribers 


Access  Line  Cost  for  I-S/A  AMPE(E)  - Terminated  Subscribers 

Cost  of  PSN- I-S/A  AMPE  Links 

Cost  of  I-S/A  AMPE(E)-I-S/A  AMPE  Links 

Cost  of  "Virtual  Mux"  - I-S/A  AMPE  Links 


Cost  of  PSN- "Virtual  Mux"  Links 


Cost  of  PSN- I -S/A  AMPE(E)  Links 


Figure  C-l.  Transmission  Cost  Breakdown 


Figure  C-2.  Transmission  Cost  Estimating  Relationships 


Legend 


number  of  PSN-PSN  links  In  the  network 


number  of  PSNs  in  the  network 


NCSF  - number  of  CSFs  In  the  network 

NI  - number  of  I-S/A  AMPEs  In  the  network 

NI(E>  - number  of  I-S/A  AMPE(E)s  In  the  network 
U - line  utilization  factor 

H - homing  Index  (H  » 1 for  single  homing,  H ■ 2 for  dual  homing) 

Fpp  - average  PSN-to-PSN  link  flow  (In  Kbps) 

CSF(xjt  “ *v#r*9*  CSF  outgoing  traffic  flow  (In  Kbps) 

Fpj  - average  PSN-to-I-S/A  AMPE  link  flow  (In  Kbps) 

FEp  - average  I-S/A  AMPE(E)-to-PSN  link  flow  (In  Kbps) 

PIE  * fraction  of  I-S/A  AMPEs  which  are  connected  to  I-S/A  AMPE(E)s 

(the  same  fraction  Is  used  for  I-S/A  AMPEs  connected  to  "vir- 
tual multiplexers") 

Dpp  - average  PSN-PSN  mileage 

0P£  - average  PSN-CSF  mileage 

Dp | - average  PSN-I-S/A  AMPE  mileage 

Dpc  - average  PSN-I-S/A  AMPE(E)  mileage 


Figure  C-2.  (Continued) 


Monthly  transmission  costs  for  the  three  alternatives,  as  a 
function  of  the  number  of  service  elements  (CSFs  and/or  I-S/A  AMPE(E)s), 
are  presented  In  Tables  C-I I and  C-I TI . The  two  cases  represent  different 
fractions  of  I-S/A  AMPEs  directly  connected  to  PSNs  (Instead  of  PSN  con- 
nection through  an  Intermediate  element,  such  as  an  I-S/A  AMPE(E)). 

From  the  results  obtained.  It  Is  apparent  that  there  Is  no 
significant  variation  In  transmission  cost  among  the  three  alternatives. 

As  would  be  expected.  Architecture  I shows  a slightly  greater  cost  than 
the  other  two  alternatives.  This  stems  from  the  fact  that  all  traffic 
requiring  services  must  access  a backbone- homed  CSF.  On  the  other 
hand.  Alternatives  II  and  III  offer  some  or  all  of  these  services 
closer  to  the  subscriber.  In  access  area  elements.  In  any  event,  the 
variation  In  total  cost  Is  no  greater  than  about  6%.  If  costs  common 
to  all  three  architectures  were  Included,  this  variation  would  be 
further  reduced. 

In  Tables  C-I I and  C-I I I the  number  of  service  elements 
and  the  connection  strategy  for  I-S/A  AMPEs  were  chosen  as  architec- 
tural variables,  while  holding  other  parameters  constant.  In  order  to 
assess  the  Impact  of  several  of  the  assumptions  discussed  earlier,  the 
sensitivity  of  the  results  to  changes  In  these  parameters  was  Investi- 
gated. The  parameters  were  varied  over  a reasonable  range  of  values 
so  as  to  Identify  trends  In  the  behavior  of  the  cost  results.  The 
findings  are  summarized  In  Table  C-IV.  As  Indicated  In  the  table, 
variations  In  most  parameters  tend  to  affect  all  three  architectures 
fairly  equally,  thus  producing  no  significant  effect  on  the  com- 
parative evaluation. 

It  should  be  noted  that  the  cost  comparison  applies  to 
1988  configurations.  However,  given  the  similar  topologies 
of  the  three  architectures,  as  well  as  the  likelihood  of  comparable 
1983-1988  transition  plans,  the  results  can  be  expected  to  hold 
throughout  the  mid-term. 

In  view  of  these  considerations,  transmission  cost  does  not 
represent  a driving  factor  In  the  selection  of  a preferred  archi- 
tecture. The  cost  variations  obtained  are  of  the  same  order  of  magni- 
tude as  the  error  associated  with  many  of  the  underlying  assumptions. 

Thus,  no  alternative  can  be  singled  out  as  best  and  the  three  archi- 
tectures have  been  ranked  equally. 


b.  Nodal  Element  Acquisition  Cost.  The  comparative  evaluation 
of  potential  acquisition  costs  for  the  alternative  mid-term  architec- 
tures relied  on  the  following  guidelines  and  assumptions: 


TABLE  C-II.  TRANSMISSION  COST  RESULTS 
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-IV.  TRANSMISSION  COST  SENSITIVITY  ANALYSIS 


.T  GREATER  FOR  ARCHITECTURE  I 


The  estimation  of  acquisition  costs  focused  on  nodal  ele- 
ment hardware  costs,  as  well  as  basic  operating  system 
software  costs.  A software-first  development  approach 
was  assumed  for  applications  software  (which  supports 
AUTOOIN  functions  and  services),  uslnc  transportable 
software  modules  designed  to  run  on  all  of  the  alternative 
hardware  configurations.  Since  all  three  archl tectures 
must  provide  the  same  functions  and  services,  applications 
software  development  costs  were  regarded  as  architecture 
Independent  and  excluded  from  the  analysis. 

Security  functions  (e.g.,  access  control,  key  distribution) 
and  multilevel  security  are  to  be  provided  through  separate 
subsystem.  As  mentioned  earlier,  these  Issues  were 
addressed  under  technical  rather  than  cost  criteria  (see 
Appendix  D).  In  any  event.  It  Is  expected  that  the  Imple- 
mentation cost  will  be  fairly  uniform  for  the  three  alter- 
natives. 

The  cost  of  militarization  of  nodal  element  hardware  (I-S/A 
AMPE.  I-S/A  AMPC(E)  and  CSF)  has  beer,  excluded  from  the 
analysis.  The  requirements  for  militarization  of  nodal 
element  hardware  are  Independent  of  architecture. 

Although  some  nodal  elements  may  be  leased,  the  cost  esti- 
mating approach  made  use  of  one-time  acquisition  costs  for 
convenience.  In  situations  requiring  an  annual  cost  figure, 
the  one-time  cost  was  distributed  uniformly  over  a ten  year 
economic  lifetime. 

In  the  specification  of  nodal  hardware  configurations  max- 
Imum  commonality  and  modularity  were  assumed.  Furthermore, 
the  nodal  elements  were  based  on  a multiprocessor  archi- 
tecture. 

Cost  estimates  for  network  elements  were  based  on  ammer- 
clal  hardware  suitable  for  a fixed  plant  environment,  and 
do  not  Include  the  cost  of  spare  parts,  documentation  or 
other  support  costs. 

Acquisition  cost  figures  are  expressed  In  1978  dollars. 

In  accordance  with  the  preceding  ground  rules,  acquisition 
costs  of  all  major  network  elements  were  estimated  using  the  approach 
described  below. 
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Representative  hardware  configurations  were  defined  for 
the  nodal  elements  of  each  alternative  architecture  (PSNs 
were  assuaed  architecture  Independent,  and  excluded  from 
the  analysis).  These  configurations  are  required  to  support: 

• Communications  Processing 

- Service  Processing 

- Control  Processing. 

Each  el  went  was  defined  In  teras  of  a standard  set  of  hard- 

ware components  (e.g. , processor,  memory , peripherals)  se- 
lected from  typical  state-of-the-art  communications  pro- 
cessing systems. 


The  network  elements  were  sized,  using  the  set  of  standard 
components,  based  on  the  following  Inputs: 

- The  functional  capabilities  required  to  support  ser- 
vices allocated  to  the  nodal  elements 


The  projected  nodal  throughput  requirements  provided 
by  the  automated  traffic  model 

Typical  subscriber  circuit  and  network  trunk  Inventories 
(classified  according  to  transmission  speed  and  link 
protocol),  derived  from  available  AUTODIN  projections. 


These  Inputs  were  used  to  determine  the  requirements  for 
processing  power,  memory  and  peripherals,  as  well  as  the 
operating  system  to  manage  them. 


Network  element  costs  were  then  computed,  based  on  hard- 
ware component  cost  estimates  collected  through  vendor 
surveys  and  available  literature. 


Finally,  the  total  nodal  element  acquisition  cost  was 
compiled  for  each  alternative  mid-term  architecture,  using 
the  typical  network  configuration  of  Table  C-I. 


The  Tymshare  Engine,  a commercial  processor,  was  selected 
as  the  basic  building  block  In  defining  nodal  element  configurations. 
This  unit,  used  as  a nodal  processor  In  a value-added  network  (Tymnet), 
was  chosen  for  several  reasons: 

The  Engine  was  specifically  designed  for  communications 
processing. 

It  Is  suitable  for  a multiprocessor  nodal  architecture, 
and  Is  fairly  modular  In  structure. 
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It  evolved  from  the  Interdata  7/32,  a well-known  mini- 
computer. Furthermore: 


- It  Is  similar  to  the  ATP-5/6,  a version  of  the  AMPE 
which  Is  also  based  on  the  7/32 

- It  Is  software  compatible  with  the  7/32,  and  Is  support- 
ed by  the  same  peripherals 

- It  Is  a more  powerful  enhanced  version  of  the  7/32. 

The  Engine  Is  representative  of  state-of-the-art  technology. 

The  Engine  should  be  viewed  as  a "strawman”  hardware  Imple- 
mentation useful  In  a comparative  analysis,  rather  than  a nodal  arch- 
itecture recoamwndatlon. 

The  nodal  elmnnt  hardware  sizing  procedure  Is  Illustrated 
In  Figure  C-3,  for  the  case  of  an  I-S/A  AMPE  (comon  to  all  three 
architectures).  The  configuration  Includes  two  Engine  processors, 
one  for  communication  processing  and  one  for  service  processing 
(with  control  functions  present  In  both),  as  well  as  the  necessary 
peripherals,  storage  devices  and  I/O  ports. 

To  avoid  redundant  effort,  the  specification  of  hardware 
configurations  was  performed  on  network  elements  In  order  of  In- 
creasing capability.  In  this  way,  the  structure  of  one  element  could 
build  on  the  hardware  configuration  of  a less  powerful  element  (which 
supports  a subset  of  the  functions  and  services  of  the  first  one) 
by  adding  extra  components  and  capabilities.  The  results  of  the 
nodal  element  acquisition  cost  analysis  are  shown  In  Figure  C-4.  *he 
diagram  also  depicts  the  order  In  which  these  elements  were  con- 
figured, starting  from  a set  of  standard  components.  The  cost  of  an 
I-S/A  AMPE  was  calculated  In  spite  of  Its  architecture  Independence, 
since  It  represents  an  Intermediate  step  In  the  definition  of  an  I-S/A 
AMPE(E).  The  ‘large"  and  "small"  versions  of  the  I-S/A  AMPE(E)s  re- 
sult from  different  assiaad  I-S/A  AMPE(E)  populations.  The  smaller, 
more  pervasive  type  Is  assimwd  In  the  typical  configurations  presented 
In  Table  C-I  and  used  throughout  this  study. 

Based  on  typical  1988  network  configurations  and  derived 
element  acquisition  costs,  the  overall  acquisition  cost  for  each 
alternative  architecture  was  computed.  The  results  are  sumarlzed 
In  Table  C-V.  Elements  Irrelevant  to  a comparative  analysis  have 
been  excluded.  It  Is  evident  from  the  results  that  total  nodal  ele- 
ment acquisition  cost  does  not  vary  greatly  among  the  alternatives. 

In  addition,  when  the  expected  economic  life  of  the  elmaents  Is  con- 
sidered (around  10  years),  the  potential  difference  In  annual  lease 
cost  becomes  Tess  significant. 


TABLE  C-V 


PROJECTED  NETWORK  ELEMENT  ACQUISITION  COST 


Several  observations  should  be  made  In  the  area  of  sensi- 
tivity* First,  the  simplifying  assumption  of  uniform  software  de- 
velopment costs  does  not  reflect  the  additional  complexity  and  cost 
of  developing  and  Implementing  software  for  more  than  one  service 
element.  Taking  this  Into  account  would  penalize  Alternative  III 
while  making  Alternative  II  more  attractive.  The  likely  effect 
would  be  to  reverse  the  acquisition  cost  ranking  presented  In  Table  C-V, 
showing  a slight  preference  for  Architecture  II.  The  variation  In 
cost,  however,  should  still  be  relatively  Insignificant. 

Finally,  the  assumption  that  would  appear  to  have  the 
greatest  Impact  on  the  acquisition  cost  ranking  Is  the  number  of 
network  elements  (l.e.,  the  assumed  1988  configurations).  However, 
because  of  performance  and  survivability  constraints,  no  appreciable 
variation  from  the  nominal  values  Is  anticipated.  Furthermore,  the 
cost  advantage  of  a decrease  In  the  population  of  a service  element 
Is  partially  offset  by  an  Increase  In  unit  cost  for  the  remaining 
elements,  arising  from  additional  throughput  and  service  processing 
requirements. 


c.  Operation  and  Maintenance  Cost.  Of  the  major  components  of 
operation  and  maintenance  (0  & M)  cost  - personnel , spares  and  back- 
up equipment,  facilities  support  (0  & M of  Installations),  and 
utilities  - personnel  costs  represent  the  largest  contribution  to 
total  cost.  In  view  of  this,  the  analysis  of  operation  and  mainte- 
nance cost  focuses  on  personnel  requirements,  and  addresses  the  re- 
maining factors  In  terms  of  the  sensitivity  of  the  results. 

The  basic  approach  to  calculating  personnel  costs  for  the 
candidate  architectures  Is  described  below: 

Nanning  requirements  for  each  nodal  element  type  (by  per- 
sonnel category)  were  estimated  based  on  available  history 
of  existing  ASC  and  AMPE  operations 

Average  annual  costs,  by  personnel  category,  were  computed 
based  on  available  OCA  cost  Information 

The  total  personnel  requirements  and  resultant  annual  costs 
were  compiled  for  each  alternative,  using  the  typical  1988 
nodal  element  Inventories  presented  In  Table  C-I. 

Projected  manning  requirements  and  annual  pay  rates  (by 
personnel  category)  used  throughout  the  operation  and  maintenance  cost 
analysis  are  shown  In  Table  C-VI.  The  table  Includes  present  ASC  and 
AMPE  levels  for  reference,  as  well  as  estimated  levels  for  nodal 
elements  used  In  the  alternative  mid-term  architectures  and  the  pro- 
jected baseline. 


PERSONNEL  REQUIREMENTS  ESTIMATES 


TABLE  C-VI.  (Continued) 


Notes 

1.  "ASC  1988  Levels”  represent  reduced  0 & M personnel  requirements 
that  will  result  from  Introduction  of  new  technology  replacement 
subsystem  during  1978-1988  period  (e.g..  second  generation  crypto 
equipments). 

2.  "AMPE  1988  Levels  (Original)”  represents  0 & M personnel  require- 
ments for  AMPEs  which  are  deployed  during  the  near-term  and  remain 
In  operation  throughout  the  mid-term.  The  only  personnel  reduc- 
tion relative  to  present  levels  arises  In  the  area  of  crypto  main- 
tenance* as  a result  of  the  Introduction  of  second  ^neratlon 
equipment. 

e 

3.  "AMPE  1988  Levels  (Replacement)"  represent  0 & M personnel  require- 
ments for  AMPEs  which  are  deployed  during  the  mid-term  to  replace 
certain  near-term  AMPEs.  These  replacement  AMPEs  show  a reduction 
In  hardware  maintenance  requirements  as  a result  of  a certain  de- 
gree of  standardization  and  technological  Innovation  In  many  of 
the  subsystems. 

4.  Manning  levels  Include  only  those  personnel  whose  primary  respon- 
sibility centers  around  the  proper  functioning  of  the  network 
elements. 

5.  The  Hardware  Maintenance  category  has  been  Included  for  comparative 
purposes  (In  many  Instances  this  service  Is  provided  by  a contractor). 

6.  The  Facilities  Operations  & Maintenance  category  Includes  power 
production*  air  conditioning  maintenance,  etc. 

7.  The  personnel  requirements  represent  site  totals,  assuming  four 
shifts. 

8.  Manning  levels  are  assumed  to  be  averaged  over  the  total  population 
of  an  element  (both  CONUS  and  Overseas). 

9.  Yearly  costs  are  weighted  averages  of  the  ASC  personnel  breakdown 
under  each  major  category.  The  appropriate  rates  are  taken  from 
Reference  b and  Include  base  pay  plus  costs  for  retirement,  train- 
ing, recruiting  and  other  support  costs.  Costs  are  In  1977  dollars. 
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The  estimates  for  ASC  and  AMPE  personnel  were  obtained  from 
available  data  on  existing  operations.  In  particular,  personnel 
requirements  for  the  ASCs  are  based  on  1977  authorized  levels  for 
the  Crouahton  and  Plrmasens  Installations.  They  Include  some  Indirect 
personnel  (l.e.,  those  whose  primary  duty  Is  outside  the  Sensitive 
Compartmented  Information  (SCI)  Accredited  Area),  primarily  In  the 
areas  of  facilities  0 & M and  hardware  maintenance.  Some  categories 
have  been  aggregated  for  simplicity  (e.g..  Hardware  Maintenance  Includes 
Computer,  DSTE,  Teleypewrlter  and  Modem  Maintenance).  The  standard 
personnel  categories  used  throughout  the  manning  analysis  are  Indicated 
In  Table  C-VI . Estimates  for  AMPE  personnel  requirements  were  based  on 
proposed  manning  levels  for  the  Stuttgart  AME  and  additional  Informa- 
tion on  operation  and  maintenance  personnel  found  In  Reference  a as  a 
starting  point.  In  order  to  ensure  a meaningful  comparison  among 
network  elements,  the  personnel  categories  from  both  sources  were  mapped 
Into  the  standard  categories  developed  for  the  ASC.  An  example  of  this 
mapping  for  the  Stuttgart  AMME  Is  shown  In  Table  C-VI I.  (Those  cate- 
gories not  Incljded  In  the  AMME  reference  were  estimated  by  extrapo- 
lation from  Reference  a and/or  available  estimates  for  the  same  cate- 
gories.) Finally,  the  requirements  for  each  category  were  adjusted  to 
account  for  variations  In  AMPE  types  and  sizes  (the  values  In  Table  C-VI 
represent  overall  averages.) 

The  manning  estimates  for  proposed  new  IAS  elements  were 
obtained  using  the  available  ASC  and  AMPE  Information  as  a baseline. 
These  figures  were  then  projected  and  adjusted  for  each  elemerr  In 
question,  with  consideration  given  to: 

Element  throughput  requirements 

Anticipated  processing  capabilities 

Coemunl cation  line  and  trunk  terminating  requirements 

Advances  In  technology 

The  following  additional  assumptions  and  guidelines  were 
used  In  preparing  Table  C-VI: 

The  Hardware  Maintenance  category  has  been  included  for 
comparative  purposes,  to  Illustrate  the  potential  savings 
offered  by  the  new  IAS  elements  (maintenance  Is  provided  by 
contractors  In  all  CONUS  and  many  overseas  elements). 

The  manning  levels  shown  In  the  table  Include  more  than 
just  the  operations  personnel  (as  found  In  many  refer- 
ences), but  are  restricted  to  personnel  whose  primary 
responsibility  centers  around  the  proper  functioning  of 
the  network  element. 
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The  personnel  requirements  represent  site  totals,  assuming 
four  shifts. 
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Manning  levels  are  assumed  to  be  averaged  over  the  total 
population  of  an  element  (both  CONUS  and  Overseas). 

. Yearly  costs  were  weighted  averages  of  the  ASC  personnel 
breakdown  under  each  major  category.  The  appropriate  rates 
are  taken  from  Reference  b (Tables  23-2  and  24-2)  and  include 
base  pay  plus  costs  for  retirement,  training,  recruiting  and 
other  support  costs  (according  to  OCAI  600-60-1).  Cost 
figures  are  in  1977  dollars. 

From  the  information  derived  on  manning  levels  and  costs, 
system  personnel  requirements  and  total  annual  costs  were  computed 
for  the  alternative  architectures.  The  results  are  sunmarized  in 
Table  C-VIII.  As  indicated  in  this  table.  Alternative  II  represents 
a savings  of  approximately.  200  personnel  which  would  result  in  an 
estimated  annual  0 & M cost  reduction  of  approximately  $4  million. 

This  savings  results  primarily  from  the  fact  that  Alternative  II 
requires  fewer  nodal  element  installations  than  the  other  architectures 
to  provide  the  same  performance,  services  and  geographical  coverage. 
Although  the  remaining  components  of  operation  and  maintenance 
cost  (discussed  earlier)  were  not  calculated  in  this  analysis,  it 
can  be  expected  that  consideration  of  additional  0 & M factors  would 
increase  the  cost  advantage  of  Architecture  II  over  the  other  alterna- 
tives. This  is  so  because  the  various  types  of  nodal  elements  require 
similar  Installations,  and  hence  the  total  cost  of  these  additional 
factors  tends  to  be  primarily  a function  of  the  number  of  elements 
(thus  favoring  the  alternative  with  the  smallest  element  Inventory). 

As  discussed  earlier  in  the  appendix,  no  significant  variation  in 
the  assumed  1988  element  inventories  is  anticipated. 

In  view  of  these  considerations.  Architecture  II  is  pre- 
ferred from  an  0 4 M cost  standpoint.  However,  considering  the 
magnitude  of  error  associated  with  some  of  the  basic  assumptions, 
the  cost  advantage  is  not  significant  enough  to  eliminate  the  other 
alternatives  from  consideration. 

d.  Total  System  Cost  Comparison  Summary.  In  order  to  obtain 
a meaningful  overall  ranking  of  the  alternatives  based  on  their  cost 
performance,  the  relative  weight  of  each  cost  category  must  be  con- 
sidered. Although  the  comparative  cost  analysis  specifically 
avoided  calculating  costs  common  to  all  alternatives,  sufficient 
Information  Is  available  to  permit  first  order  estimates  of  the  total 
system  costs: 


Transmission  Costs  - the  comparative  analysis  yielded  an 
annual  cost  of  about  $6  million  ($500K/mo)  for  CONUS.  In- 
clusion of  the  architecture  independent  portion  of  access 
area  costs  (C..(K)),  and  extension  of  the  analysis  to  over 
seas,  produces^  figure  of  approximately  $20  million  per 
year. 
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TABLE  C-VIII.  PROJECTED  O&M  PERSONNEL  COST 


ARCHITECTURE 

ALTERNATIVE 

NOOAl  ELEMENT 
INVENTORY 

PERSONNEL 

REQUIRED 

ESTIMATED 
ANNUAL  OQM 
PERSONNEL  COST 
(10n  SK  PER  YEAR) 

10PSN 

B3Q 

12,220 

1 

BCSF 

372 

7.270 

71  l-S/A  AMPE 

♦ B.8B4 

♦ 133,045 

7.BM 

152.544 

10PSN 

130 

12.220 

II 

IS  l-S/A  AMPE  (E) 

1,470 

20,425 

S3  l-S/A  AMPE 

♦ 5,544 

♦ 107,470 

7,044 

140,123 

18PSN 

030 

12420 

III 

• CSF 

270 

5,440 

12  l-S/A  AMPE  (E) 

1,12S 

21,f4f 

« l-S/A  AMPE 

♦ 5.  BOB 

112,504 

7,042 

152.110 

NOTES: 

1.  NODAL  ELEMENT  INVENTORIES  ARE  BASED  ON  TYPICAL  IBM  NETWORK 
CONFIGURATIONS. 

2.  PERSONNEL  REQUIREMENTS  REPRESENT  SITE  TOTALS.  ASSUMING  FOUR 
SHIFTS. 

X AVERAGE  YEARLY  COSTS  ARE  BASED  ON  PERSONNEL  RATES  PONMN  Hi 
REFERENCE  h. 
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. Nodal  Element  Acquisition  Costs  - the  comparative  analysis 
showed  an  annual  cost  of  approximately  $40  million.  The 
addition  of  costs  common  to  the  three  alternatives  (such 
as  software  development.  Installations,  etc.)  Is  expected 
to  double  this  figure.  Amortization  over  a 10-year  economic 
life  yields  an  estimated  annual  cost  of  $10  million. 

. Operation  and  Maintenance  Costs  - the  analysis  of  personnel 
costs  was  quite  comprehensive,  and  led  to  an  annual  figure 
of  about  $150  million.  Additional  0 & M costs  utilities, 
facilities  support,  and  spares,  suggest  a total  annual  cost 
of  approximately  $200  million. 

In  summary,  the  transmission  cost  will  be  essentially  the 
same  for  each  alternative  (approximately  $10  M per  year).  The  system 
acquisition  cost  may  be  slightly  higher  for  Alternative  II  than  the 
other  two  alternatives  ($10  M vice  $9  M per  year)  and  the  0 & M cost 
for  Alternative  II  may  be  slightly  lower  ($195  M versus  $200  M per 
year).  As  a result.  Architecture  II  seems  to  offer  a slight  ad- 
vantage over  the  other  alternatives  In  terms  of  the  total  cost  of 
ownership.  However,  the  total  cost  impact  of  any  architecture  choice 
Is  probably  less  than  10  percent  of  the  total  annual  cost  of  the  IAS. 
Therefore,  no  alternative  can  be  eliminated  solely  on  the  basis  of  cost. 


3.  COMPARISON  OF  MID-TERM  ARCHITECTURE  TO  PROJECTED  BASELINE 

a.  The  Projected  Baseline.  In  order  to  gain  Insight  Into  the 
potential  advantage  to  DCA  of  Implementing  any  of  the  alternative 
mid-term  IAS  architectures,  the  comparative  cost  analysis  was  expanded 
to  Include  comparison  of  Architecture  II  with  the  1983  baseline 
architecture  projected  to  a probable  1988  configuration  (presented 
In  Table  C-I).  The  projected  baseline  architecture  used  In  this 
analysis  would  Incorporate  only  those  changes  and  upgrades  required 
to  maintain  current  system  capabilities.  The  projected  baseline, 
when  compared  with  the  mid-term  architecture,  provides  a clear 
Indication  of  the  Impact  that  will  result  If  little  or  no  action  Is 
taken  toward  the  evolution  of  the  AUTODIN  system.  In  addition,  this 
comparison  clearly  emphasizes  the  potential  cost  savings  of  the  mid- 
term architecture. 
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The  projected  1983  baseline  architecture  Is  based  on  the 
following  assumptions: 

. ASCs  retained  In  operation  with  minimum  essential  hardware/ 
software  subsystem  replacement 


AMPEs  retained  In  all  current  locations 
end  of  their  useful  service  life  with  a 


and  replaced  at  the 
"standardized"  AMPE. 
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Based  on  current  OoO  policy,  the  projected  baseline  architecture 
Includes  provision  for  replacement  of  existing  AMPEs  with  some  form 
of  standardized  AMPE.  However,  because  these  equipments  would  not 
have  the  additional  capability  of  the  I-S/A  AMPE  used  In  the  mid- 
term architecture.  It  Is  unrealistic  to  assume  that  consolidation 
could  be  achieved  In  the  projected  1983  baseline  architecture. 
Therefore,  the  number  of  AMPEs  projected  for  the  1988  configuration 
was  derived  from  current  and  planned  AMPE  requirements  (see  Appendix 
A). 


The  comparison  between  the  Architecture  II  and  the  pro- 
jected baseline  centers  on  major  cost  elements,  as  before,  but  ex- 
tends some  categories  to  Include  comnon  factors  (such  as  PSN  and  AMPE 
costs).  This  helps  provide  a feel  for  the  order  of  magnitude  of  the 
absolute  costs. 


b.  Transmission  Cost.  The  comparative  analysis  of  transmission 
cost  of  subsection  2a.  revealed  very  little  cost  sensitivity  to  the 
architectural  configuration  or  the  basic  underlying  assumptions. 
Furthermore,  the  projected  baseline  must  provide  the  same  geographical 
coverage,  and  meet  the  same  performance  requirements  as  the  alter- 
native mid-term  architectures.  Therefore,  no  significant  difference 
In  link  configurations  Is  anticipated.  Any  of  the  candidate  mid-term 
architectures  may  yield,  however,  some  cost  savings,  arising  from 
the  more  effective  use  of  traffic  concentration  and  nodal  processing. 


c.  Nodal  Element  Acquisition  Cost.  A comparison  of  projected 
network  element  acquisition  cost  for  Architecture  II  versus  the 
projected  baseline  was  performed,  using  the  same  basic  approach  and 
assumptions  outlined  In  subsection  2b.  The  results  are  summarized 
In  Table  C-IX.  Only  acquisitions  unique  to  each  architecture  have 
been  Included  (original  AMPEs  remaining  In  1988  and  PSNs  are  present 
In  both  alternatives).  The  cost  of  replacement  AMPEs  ("standardized1*) 
was  estimated  at  80%  of  the  t-S/A  AMPE  cost,  using  the  sizing  approach 
described  earlier  in  this  appendix.  As  evidenced  by  the  results, 
total  estimated  acquisition  cost  of  the  Architecture  II  Is  approxi- 
mately $3.3  million  greater  than  that  of  the  projected  baseline. 
However,  when  total  useful  service  life  of  the  elements  Is  considered, 
the  cost  Impact  Is  relatively  Insignificant. 


d.  Operation  and  Maintenance  Cost.  The  comparison  of  operation 
and  maintenance  cost  for  Architecture  II  versus  the  projected  baseline 
followed  the  same  procedure  and  assunptlons  used  to  evaluate  the 
alternative  architectures.  The  analysis  focused,  again,  on  personnel 
costs,  and  the  comparative  results  are  summarized  In  Table  C-X.  As 
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TABLE  C-IX.  NODAL  ELEMENT  ACQUISITION  COST  COMPARISON 


required 

ACQUISITIONS 


II  I- S/A  AMPE  (E) 


ARCHITECTURE  (II)  S3  l-S/A  AMPE 


ESTIMATED  COST 
PER  ELEMENT 


(1171 » 
SYSTEM  COST 


117  AM* 
(REPLACEMENT) 


1.  EACH  ELEMENT  NAS  SEEN  OEFINED  IN  TERMS  OP  HARDWARE  COMPONENTS 
SELECTED  PROM  TYPICAL  STATE-OF-THE-ART  COMMUNICATIONS  PROCESSING 
SYSTEMS. 

1 COST  ESTIMATES  REPRESENT  PROJECTED  ACQUISITION  COSTS  FOR  NETWORK 
ELEMENTS  BASED  ON  COMMERCIAL  HARDWARE  SUITABLE  TO  A PIXEO  PLANT 
ENVMONMENT.  ANO  00  NOT  INCLUOE  THE  COST  OF  SPARE  PARTS.  DOCUMENTS 
TION.  OR  OTHER  SUPPORT  COSTS. 

1 COST  ESTIMATES  00  NOT  INCLUOE  AMORTIZATION  OP  HARDWARE  OR  SOFT- 
WARE DEVELOPMENT  COSTS. 

1 ELEMENT  INVENTORIES  ARE  BASED  ON  TYPICAL  1SBI  NETWORK  CONPIOURA- 
THINS. 

1 SUNK  COSTS  INCLUDING  PSNt,  TERMINALS.  ETC.  HAVE  SEEN  EXCLUOEO  FROM 
TNI  COST  COMPARISON. 

S THE  AMPEt  SHOWN  IN  THE  PROJECTED  BASELINE  ELEMENT  INVENTORY 
ARE  STANDARDIZED  AMPEt WHICH  REPLACE  CURRENT  (NEAR-TERM) 

AMPEt  OURING  THE  MID-TERM. 

7.  THE  COST  OF  REPLACEMENT  AMPEt  WAS  ESTIMATEO  AT  ION  OF  THE 
l-S/A  AMPS  COST. 


evidenced  by  this  tabic.  Architecture  II  offers  a potential  net 
savings  of  over  2500  personnel  with  a resultant  net  cost  savings 
of  almost  $50  million  per  year.  It  should  be  noted  that  the  cost 
analysis  takes  Into  account  the  fact  that  many  of  the  existing  and 
planned  AMPE  sites,  eliminated  through  consolidation,  will  revert  to 
local  terminal /message  center  operation.  As  a result,  many  of  the 
0AM  personnel  formerly  required  at  the  AMPE  sites  will  be  retained 
for  operation  of  the  terminal /message  centers  (see  Table  C-VI).  The 
magnitude  of  the  potential  savings  Indicated  by  this  analysis  demon- 
strates clear  opportunity  for  significant  reduction  of  total  AUDOOIN 
system  operation  and  maintenance  cost  through  Implementation  of  any 
of  the  alternative  mid- term  IAS  architectures. 
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V APPENDIX  0 

DETAILED  EVALUATION  OF  ALTERNATIVE  ARCHITECTURES 
FOR  THE  MID-TERM  IAS 


1.  INTRODUCTION 

In  order  to  determine  the  preferred  Mid-Term  IAS  Architecture,  the 
three  alternative  architectures  dascribad  In  Saction  II  of  this  report 
were  avaluatad  with  raspact  to  thalr  affact  on  system  parfortaanca.  Ob- 
viously, tha  actual  performance  of  tha  Mid-Tam  IAS  system  cannot  be 
accurately  predicted  solely  on  tha  basis  of  an  archltactural  level  defi- 
nition, since  detailed  system  performance  requirements  (based  on  future 
user  applications  and  needs)  cannot  be  specified  until  much  later  In  tha 
system  definition  and  design  cycle.  Also,  It  must  be  remembered  that 
each  alternative  architecture,  by  definition,  Is  capable  of  meeting  the 
anticipated  future  performance  requirements  of  tha  Mid-Tam  IAS  (to  tha 
extant  that  these  requirements  are  known)  within  tha  limits  of  available 
technology.  Tha  thrust  of  this  evaluation  process,  therefore,  was  to 
Identify  significant  differences  at  the  architectural  level  among  al- 
ternatives In  terns  of  the  expected  difficulty,  complexity,  or  risk  that 
would  be  encountered  In  providing  a given  level  of  perfomance.  As  a 
result,  this  evaluation  concentrates  on  the  differences  among  archi- 
tectures and  does  not  attempt  to  predict  the  absolute  perfomance  of  any 
alternative. 


a.  Purpose.  This  appendix  describes  the  evaluation  criteria  and 
analysis  process  used  to  evaluate  alternative  architectures  for  the  Mid- 
Term  IAS.  In  addition,  this  appendix  presents  the  results  of  the  evalu- 
ation process  and  describes  the  significant  differences  between  alterna 
tlves  Identified  In  the  evaluation  process  with  respect  to  each  evalua- 
tion criterion.  Finally,  this  appendix  summarizes  the  overall  results 
of  the  evaluation  process  and  provides  the  reasons  for  selection  of 
Alternative  II  as  the  preferred  Mid-Term  Architecture. 


b.  Scope.  This  analysis  addresses  the  three  candidate  archi- 
tectures described  In  Section  II  of  tne  body  of  this  report.  The  evalu 
ation  process  addresses  four  major  evaluation  criteria: 

Operational  Effectiveness 
Flexibility 

Survl vabl 1 1 ty/Aval 1 abl 1 1 ty/Supportabi 1 1 ty 
Transition. 

This  analysis  Is  limited  to  an  assessment  of  the  relative  desirability 
of  each  alternative  architecture.  No  attempt  Is  made  to  project  or 
evaluate  the  probable  system  perfomance  In  quantitative  terns. 


2.  EVALUATION  CRITERIA 

Within  each  of  th«  four  major  avaluatlon  crlttrla  Idantlflad  above, 
a number  of  subcriteria  were  Identified  as  the  first  step  In  the  analysis 
process.  The  major  evaluation  criteria  and  the  subcriteria  within  each 
criterion  are  defined  In  the  following  paragraphs. 


a.  Evaluation  Criterion  1:  Operational  Effectiveness.  This 
criterion  addresses  the  probable  Impact  of  architecture  selection  on  the 
expected  difficulty,  complexity  or  risk  of  achieving  the  required  level 
of  functional  and  operational  performance.  The  subcriteria  Identified 
within  this  evaluation  criterion  are  defined  In  the  following  subpara- 
graphs. 


(1)  Subcriterion  1:  Speed  of  Service.  This  subcriterion  re- 
fers to  the  probable  response  time  or- and- to- end  delay  performance  pos- 
sible In  the  final  system  for  a given  level  of  technical  risk  or  cost. 


(2)  Subcriterion  2:  User  Motivated  Interfaces.  This  sub* 
criterion  refers  to  the  degree  of  design  and  operational  complexity 
associated  with  user  access  to  network  services  and  user  interaction 
with  network  service  elements. 


This  sub* 


(3)  Subcriterion  3:  Transmission  Efficiency.  This  sub- 
criterion refers  to  the  relative  amount  of  overhead  Information  that 
will  be  required  for  addressing,  routing,  flow  control,  error  control, 
and  system  control. 

(4)  Subcriterion  4:  System  Motivated  Functions.  This  sub- 
criterion refers  to  the  degree  of  design  or  Implementation  complexity 
that  will  be  required  to  accomplish  network  control,  message  accounta- 
bility, technical  control,  and  traffic  control  in  the  final  system. 


(5)  Subcriterion  5: 
the  relative  difficulty  of  meet 
(see  Appendix  E). 


Security.  This  subcriterion  reflects 
ing  the  Rid-Term  IAS  Security  Objectives 


(6)  Subcriterion  6:  Adaptability  to  Overseas  Implementation. 
This  subcriterion  refers  to  the  degree  of  difficulty  and  risk  associated 
with  the  overseas  Implementation  of  network  elements  and  services. 
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b.  Evaluation  Criterion  2;  Flexibility.  This  criterion  ad- 
dresses the  ability  0/  a system  that  results  from  a given  architecture 
to  accomodate  changes  In  day-to-day  operation,  and  also  to  accomodate 
expansion  and  continued  evolution  throughout  the  mid-term  timeframe. 
These  two  aspects  of  flexibility  are  referred  to  as  adaptability  and 
expandability.  Adaptability  refers  to  the  ability  of  the  system  to 
accommodate  changes  In  the  demand  for  or  utilization  of  Its  planned 
capabilities.  Expandability  refers  to  the  ability  of  the  system  to 
accommodate  additional  requirements  In  the  future.  The  subcriteria 
Identified  within  this  evaluation  criterion  are  defined  in  the  following 
subparagraphs. 


(1)  Subcriterion  1:  Traffic  Type  Adaptability.  This  sub- 
criterion refers  to  the  relative  impact  on  overall  system  performance 
of  changes  In  user  demand  for  planned  traffic  types. 


(2)  Subcriterion  2:  External  Interface  Adaptability.  This 
subcriterion  refers  to  the  Impact  of  day-to-day  changes  In  the  volume  of 
traffic  passing  between  the  IAS  system  and  external  systems. 


(3)  Subcriterion  3:  Network  Service  Adaptability.  This  ^ 
subcriterion  refers  to  the  ability  of  the  system  to  tolerate  changes  in 
the  user  demand  between  ASC  replacement  functions  and  new  network  ser- 
vices. 


(4)  Subcriterion  4:  Subscriber/Traffic  Distribution 
Adaptability.  Thfs  subcHterion  refers  to  the  ability  of  the  system  to 
accommodate  day-to-day  changes  In  the  distribution  of  both  subscribers 
and  traffic  types. 


(5)  Subcriterion  5:  Subscriber  Expandability.  This  sub- 
criterion refers  to  the  impact  on  the  network  of  long-term  changes  in 
the  number  of  terminations  and  the  types  of  subscriber  terminations 
supported  by  the  network. 


(6)  Subcriterion  6:  Protocol  Expandability.  This  subcri- 
terion refers  to  the  relative  impact  of  adding  new  user  level,  link 
level,  and  network  level  protocols  to  the  system. 


(7)  Subcriterion  7:  Service  Expandability.  This  subcri- 
terion refers  to  the  relative  impact  of  adding  new  network  services  to 
the  network. 


(8)  Subcriterion  8:  Control  Function  Expandability.  This 
subcriterion  refers  to  the  ability  of  the  systea  to  accommodate  changes 
in  the  numbers  and  types  of  control  functions  In  the  network. 


(9)  Subcrlterlon  9:  Traffic  Expandability.  This  subcrl- 
ter Ion  refers  to  the  ability  ot  the  system  to  expand  in  teres  of  the 
volume  of  traffic  handled  by  the  network. 


(10)  Subcriterion  10:  External  Interface  Expandability. 

This  subcriterion  refers  to  the  ability  of  the  systea  to  accommodate  new 
and  additional  external  interfaces  in  the  future. 

e 

c.  Evaluation  Criterion  3:  Survlvabllltv/Ayallablllty/Supporta 
blllty.  This  criterion  considers  the  Inherent  abllillty  of  an  archi- 
tecture to  provide  the  required  systea  perforaance  In  both  normal  and 
hostile  operating  envlronaents.  The  subcriteria  Identified  for  this 
category  are  defined  In  the  following  subparagraphs. 


(1)  Subcriterion  1:  Effect  of  Failures.  This  subcriterion 
refers  to  the  expected  loss  of  service  and  user  access  resulting  from 
loss  of  a node  or  link  In  the  systea. 


(2)  Subcriterion  2:  Failure  Recovery.  This  subcriterion 
refers  to  the  difficulty  or  coaplexlty  of  the  procedures  required  to 
recover  froa  a failure  or  loss  of  a network  node  or  link. 


(3)  Subcriterion  3:  Failure  Protection.  This  subcriterion 
reflects  the  degree  to  which  an  architecture  permits  system  design  al- 
ternatives that  can  be  used  to  protect  against  failure  or  loss  of  a node 
or  link. 


(4)  Subcriterion  4;  Supportability.  This  subcriterion  re- 
fers to  the  expected  cost  and  difficulty  of  maintaining  system  per- 
foraance under  normal  conditions  (e.g. , assuming  no  hostile  actions) 
over  the  system's  life  cycle.  Supportability  is  measured  by  the  total 
number  of  elements  to  be  maintained  and  the  degree  of  commonality  among 
eleaents. 


d.  Evaluation  Criterion  4:  Transition.  This  criterion  addresses 
the  difficulty  of  evolving  from  the  current  near-term  architecture  to 
the  alternative  ald-tera  architecture.  This  criterion  also  considers 
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the  ability  of  a candidate  architecture  to  support  continued  evolution 
into  the  far- term.  The  subcriteria  identified  within  this  category  are 
defined  in  the  following  subparagraphs. 


(1)  Subcriterion  1:  Development  Risk.  This  subcriterion  re- 
fers to  the  technical  and  management  risk  associated  with  developing  the 
new  nodal  elements  required  to  implement  each  architecture. 


(2)  Subcriterion  2:  User  Impact.  This  subcriterioi  refers 
to  the  probable  impact  on  the  current  AUTOdlN  I and  AUTOOIN  V.  user 
communities  of  implementing  the  alternative  architecture. 


(3)  Subcriterion  3:  Ease  of  Implementation.  This  subcri- 
terion refers  to  the  relative  difficulty  of  implementing  the  new  network 
elements  and/or  modifying  the  existing  network  elements  in  order  to 
implement  each  architecture. 


(4)  Subcriterion  4:  Potential  for  Evolution.  This  subcri- 
terion refers  to  the  ability  of  each  architecture  to  support  continued 
evolution  beyond  the  mid-term.  The  potential  for  evolution  thus  re- 
flects the  extent  to  which  the  mid-term  IAS  can  accommodate  transition 
to  a far- term  IAS  without  constraining  far- term  alternatives. 


3.  EVALUATION  METHOOOLOGY 

As  indicated  in  Section  1,  the  level  of  detail  inherent  in  the 
description  of  an  architecture  is  not  sufficient  to  support  a predictive 
evaluation  (i.e. , an  evaluation  that  predicts  IAS  performance).  Thus  the 
evaluation  of  alternative  architectures  is  appropriately  performed  on  a 
relative  basis  in  which  the  architectures  are  compared  to  each  other 
with  respect  to  the  evaluation  criteria.  In  order  to  accomplish  the 
relative  evaluation,  the  architectures  were  ranked  with  respect  to  each 
evaluation  subcriteria,  and  a Figure  of  Merit  (FOM)  was  developed  that 
aggregates  this  set  of  rankings  into  an  overall  ranking  of  the  architec- 
tures. 

The  evaluation  process  is  conveniently  described  as  a two  stage 
process.  The  first  stage  is  the  ranking  of  architectures  with  respect 
to  each  evaluation  subcriteria.  The  second  stage  *s  the  development  of 
a FOM  for  each  architectural  alternative. 
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The  first  stage  of  the  evaluation  Is  accomplished  by  the  following 
three  steps: 

For  each  subcriterion,  examine  the  alternative  architectures 
and  Identify  potential  differences  in  system  performance  with 
respect  to  that  subcriterion 

Based  on  the  Identified  differences,  rank  the  alternatives 
from  the  most  desirable  to  the  least  desirable  (allow  ties  in 
ranking  If  differences  are  not  significant) 

Based  on  the  ranking,  assign  "quality  points"  to  each  al- 
ternative on  a scale  for  1 to  5. 

An  Important  aspect  of  this  process  is  that  any  two  alternatives  (or  all 
three)  can  be  ranked  equally  with  respect  to  a given  subcriterion.  The 
principal  advantage  of  this  approach  Is  that  evaluating  the  difference 
in  potential  performance  between  alternatives  is  reduced  to  the  binary 
decision  of  whether  one  architecture  is  "preferred"  to  another.  The 
absolute  performance  of  each  alternative  need  not  be  evaluated  in  order 
to  make  this  decision.  Thus,  the  evaluation  process  is  based  upon  a 
relative,  qualitative  assessment  consistent  with  the  degree  of  defini- 
tion inherent  in  an  architectural  description  and  based  upon  an  objec- 
tive binary  decision  process.  As  a final  step  in  this  process,  the 
qualitative  assessments  are  translated  into  numerical  quality  point 
scores  on  a scale  from  1 to  5.  The  definitions  of  these  scores  is 
presented  in  Table  0-1.  As  Indicated  by  the  table,  a numeric  score 
Is  assigned  to  each  alternative  based  on  the  preference  ranking  with 
respect  to  each  subcriterion.  In  subsequent  discussions  the  results  of 
the  evaluation  process  are  expressed  In  terms  of  these  quality  point 
scores. 

The  second  stage  of  the  evaluation  process  Is  the  aggregation  of 
the  rankings  Into  an  overall  figure  of  merit  (FOM)  for  each  alternative 
architecture.  The  steps  In  this  process  are: 

The  rankl  gs  are  first  aggregated  with  respect  to  each  evalu- 
ation criterion  as  follows:  For  each  evaluation  criterion, 
calculate  the  average  quality  point  score  by  summing  the 
individual  subcriterion  quality  point  scores  and  dividing  the 
sum  by  the  total  number  of  subcriteria 

Calculate  overall  FOM  for  each  alternative. by  summing  the 
average  quality  point  scores  for  each  evaluation  criterion. 


TABLE  D-I.  ASSIGNMENT  OF  QUALITY  POINTS 


Eva  tuition  of  Alternative 


11 tv  Point  Score 


Clearly  more  desirable  than  either  of  the  other 
alternatives 


More  desirable  than  one  of  the  other  alterna- 
tives, but  equally  desirable  to  the  remaining 
alternative 


More  desirable  than  one  alternative  and  less  de 
slrable  than  the  remaining  alternative 

No  preference  among  alternatives 


Less  desirable  than  one  of  the  other  alternatives 
but  equally  desirable  to  the  remaining  alternatives 


Clearly  less  desirable  than  either  of  the  other 
alternatives 
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For  the  purpose  of  later  discussions,  It  Is  useful  to  express  this 
process  mathematically  as  follows.  If  we  let  the  FOM  for  the  1th  al- 
ternative be  Fj,  then: 


n 

- z 

>1 


‘1j 


where  Is  the  average  quality  pclnt  score  for  the  1th  alternative 

with  respect  to  the  jth  evaluation  criterion,  and  n ■ the  number  of 
evaluation  criteria  (In  this  case,  n • 4). 


can  be  evaluated  as: 

m . 

Q1j  ’ « k?x  Q1Jk 


where  Is  the  Individual  quality  point  score  for  the  1th  alternative 

with  respect  to  the  kth  subcriterion  of  criterion  j,  and  m Is  the  number 
of  subcriteria  within  the  1th  evaluation  criterion. 

As  discussed  later  In  this  appendix,  the  contribution  of  each  cri- 
terion or  subcriterion  can  be  adjusted  through  the  Introduction  of 
weighting.  In  this  case  the  evaluation  of  Fj  and  become: 

F1  • Z V Qij 

J-i 


Q1j  " m Wjk  ‘ Q1jk 


where  Wj  Is  the  weighting  factor  for  the  jth  evaluation  criterion  and 
MJk  Is  the  weighting  factor  of  the  kth  subcriterion  of  criterion  J.  The 
next  section  presents  the  results  of  the  evaluation  process. 


4.  EVALUATION  RESULTS 

C 

This  section  presents  the  results  of  the  evaluation  process  des- 
cribed In  the  preceding  section  for  each  of  the  four  major  evaluation 
criteria.  The  quality  point  scores  as  well  as  the  significant  factors 
which  led  to  the  architecture  evaluations  for  each  subcriteria  are  pre- 
sented. 
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a.  Evaluation  Criterion  1:  Operational  Effectiveness. 

I 

(1)  Subcrlterlon  1:  Speed  of  Service.  The  principal  factors 
In  determining  tne  eventual  system  performance  in  terms  of  speed  of 
service  are  transmission  delays,  nodal  element  processing/queuing  de- 
lays, and  delays  Introduced  by  operating  procedures,  protocols,  and 
control  functions.  These  factors,  in  general,  are  determined  by  system 
design  and  Implementation  technology  rather  than  by  the  architecture. 

The  only  architectural  factor  that  Impacts  speed  of  service  Is  the 
hierarchical  structure  of  the  system  that  results  from  the  architecture. 

A measure  of  this  architectural  characteristic  Is  the  number  of  element- 
to-element  links  between  a user  and  a service  element  or  between  a user 
and  another  user  In  a normal  transaction.  Therefore,  in  order  to  evalu- 
ate the  qualitative  difference  between  architectures  for  this  subcri- 
terion, the  number  of  links  required  for  each  type  of  transaction  an- 
ticipated In  the  Mid-Term  IAS  was  calculated  for  each  alternative  archi- 
tecture. Table  D-II  presents  the  results  of  this  analysis.  As  Indi- 
cated In  the  table,  path  lengths  weree  calculated  for  Architectures  II 
and  III  assuming  the  I-S/A  AMPE  Is  singly  connected  as  well  as  assuming 
the  recoamended  configuration  where  the  I-S/A  AMPE  Is  connected  to  both 
a PSN  and  an  I-S/A  AMPE(E).  In  all  cases,  the  worst  case  backbone  path 
was  assumed  to  be  two  PSNs,  and  the.  best  case  backbone  path  was  assumed 
to  be  one  PSN.  The  evaluation  of  architecture  alternatives  was  based 
upon  the  results  of  this  analysis. 


In  general,  the  speed  of  service  performance  of  a system 
will  be  specified  in  terms  of  a worst  case  maximum  response  time  or  end- 
to-end  delay  for  each  type  of  message  or  transaction.  The  design  of  the 
system,  therefore.  Is  frequently  determined  by  the  worst  case  condition. 
The  cost  and  risk  of  meeting  the  performance  requirements  will  also 
frequently  be  determined  by  the  worst  case  design  limits.  Accordingly, 
this  evaluation  focussed  on  the  differences  between  architectures  In 
terms  of  the  maximum  path  delays  that  can  result  In  the  system.  As 
Indicated  In  Table  0- I I • If  dual  connection  of  the  I-S/A  AMPE  Is  assumed 
for  Architectures  II  and  III,  the  worst  case  path  length  for  each  archi- 
tecture Is  the  same  for  all  traffic  types  except  narrative  message 
transfer.  Since  delivery  time  for  narrative  message  traffic  Is  not  as 
critical  as  for  Interactive,  query/response  or  teleconference  traffic, 
this  difference  Is  not  considered  significant. 

As  Indicated  by  Table  D-II  there  Is  a potential  dif- 
ference between  alternatives  in  terms  of  the  best  case  delay  possible 
for  teleconference,  gateway,  message  retrieval,  and  mailbox  services. 
However,  these  best  case  differences  occur  In  Alternatives  II  and  III 
only  for  users  directly  connected  to  the  I-S/A  AMPE(E)  that  also  pro- 
vides the  network  service.  Since  most  users  will  be  connected  either 
through  an  I-S/A  AMPE  or  a PSN,  only  a small  subset  of  the  users  will 
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I -S/A  AHPEs  Duly  Connected  to  I-S/A  AMPE(E)  and  PSA 


experience  the  "best  case"  delay.  Therefore,  the  difference  Is  not 
considered  sufficient  to  create  a clear  preference  for  one  alternative. 

The  principal  result  of  this  analysis  is  evidence  of  the 
Importance  of  dual  connecting  the  I-S/A  AMPE  In  Architectures  II  and 
III.  As  shown  by  Table  D-II,  If  the  I-S/A  AMPE  Is  singly  connected  to 
the  I-S/A  AMPE(E),  the  worst  case  path  delay  for  Alternatives  II  and  III 
will  be  much  larger  than  for  Alternative  I.  This  Is  due  to  the  user  • 
I-S/A  AMPE  - I-S/A  AMPE(E)  - PSN  - PSN  - I-S/A  AMPE(E)  - I-S/A  AMPE  - 
user  path  that  can  occur  In  each  of  these  architectures.  However,  If 
the  I-S/A  AMPE  Is  connected  to  both  a PSN  and  an  I-S/A  AMPE(E),  the 
worst  case  path  for  Architectures  II  and  III  Is  reduced  to  a user  • I- 
S/A  AMPE  - PSN  - PSN  - I-S/A  AMPE  - user  path  which  Is  Identical  to 
Architecture  I.  As  a result,  the  final  Mid-Term  IAS  speed  of  service 
performance  should  not  be  greatly  affected  by  the  selection  of  any  of 
the  alternative  architectures.  Therefore,  the  three  alternative  archi- 
tectures are  ranked  essentially  equally  for  this  subcriterion  and  accord 
Ingly  the  quality  point  scores  are  as  follows: 

. Architecture  I - 3 points 

. Architecture  II  - 3 points 

. Architecture  III  - 3 points 


(2)  Subcriterion  2:  User  Motivated  Interfaces.  This  sub- 
criterion measures  the  degree  ot'  complexity  of1  the  decision  processes 
that  must  be  performed  by  IAS  users.  This  complexity  In  turn  Is  de- 
pendent on  the  following  two  numbers: 

The  number  of  different  service  elements  that  need  to  be 
accessed  by  the  user 

The  number  of  different  ways  In  which  each  service  element  can 
be  accessed. 

There  are  two  main  reasons  why  the  complexity  of  the  IAS  user  decision 
process  reduces  to  these  two  numbers.  First,  once  a user  achieves 
access  to  a network  service  element,  the  complexity  of  the  processing  Is 
a function  of  system  design  and  therefore  Is  not  an  architectural  Issue. 
Therefore,  the  analysis  of  this  subcriteria  (at  the  architectural  level) 
Is  appropriately  confined  to  analysis  of  the  process  of  accessing  ser- 
vice elements.  Secondly,  the  virtual  message  protocol  and  other  I-S/A 
AMPE  features  are  Identical  in  each  architectural  alternative.  There- 
fore, the  complexity  of  the  accessing  process  Is  the  same  In  each 
alternative.  The  complexity  of  the  user  decision  process  thus  reduces 
to  the  number  of  choices  that  the  IAS  user  has  In  accessing  the  network. 
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In  Architecture  I 
This  elefNnt  Is  the  CS 


In  Architecture  il  there  Is  only  one  type  of  service 
element.  This  element  Is  the  CSF.  All  traffic,  regardless  of  type, 
must  be  routed  directly  to  the  nearest  CSF  for  processing.  Therefore, 
the  accessing  procedures  and  netvtork  protocols  employed  In  Archltectun 
I have  the  least  complexity  possible. 


Architecture 


Architecture  II,  like  Architecture  I,  has  only  one  type 
of  service  element.  This  element  Is  the  I-S/A  AMPE(E).  However,  In 
Architecture  II,  unlike  Architecture  I,  the  service  element  can  be 
accessed  two  different  ways: 

Direct  access  by  locally  connected  subscribers 
Remote  access  through  the  network. 

The  existence  of  two  access  approaches  to  the  I-S/A  AMPE(E)  appears  to 
cause  Architecture  II  to  require  more  complex  user  processing  than 
Architecture  I.  However,  the  actual  Increase  In  complexity  need  not  be 
significant,  because  the  additional  processing  steps  Implied  by  the  two 
access  approaches  can  be  embodied  In  the  design  of  the  I-S/A  AMPE(E) 
Itself  and  thus  can  be  separated  from  the  user  level  equipment. 

Architecture  III  has  both  the  CSF  and  I-S/A  AMPE(E). 
Network  services  are  divided  between  these  two  service  element  types. 
Furthermore,  at  least  some  users  (e.g. , those  directly  connected  to 
PSNs)  will  be  required  to  make  addressing  and  routing  decisions  based 
on  the  type  of  service  required  for  each  transaction.  Consequently, 
Architecture  III  Is  less  desirable  than  Architectures  I and  II  with 
respect  to  this  subcriterion.  Accordingly  the  quality  point  scores  are 
as  follows: 


Architecture  I 
Architecture  II 
Architecture  III 


4 points 
4 points 
1 point. 


(3)  Subcriterion  3:  Transmission  Efficiency.  Transmission 
efficiency  reflects  the  relative  amount  of  overhead  Information  required 
for  addressing,  routing,  flow  control,  error  control,  and  system  control. 
Since  the  overhead  required  for  addressing  and  routing  Is  essentially  a 
function  of  the  number  of  subscribers  and  switching  elements  contained 
In  the  system  and  since  these  numbers  are  system  design  and  Implementa- 
tion Issues,  no  major  differences  were  seen  between  the  alternatives 
within  these  areas. 


Tha  overhead  raqulrad  to  accomplish  traffic  control  is 
considarad  assantially  tha  s ana  for  aach  architactura.  If  dual  connac- 
tion  of  tha  I-S/A  AMPEs  is  assumad,  as  indicatad  in  tha  spaad  of  sarvica 
analysis,  tha  avaraga  transmission  paths  will  ba  assantially  tha  saaa 
for  aach  altarnativa.  Tharafora,  tha  amount  of  ovarhaad  raprasantad  by 
arror  control  procaduras  (rasulting  from  and-to-and  arror  rata  dlf- 
farancas)  will  ba  assantially  tha  sama  for  aach  altarnativa. 

From  tha  standpoint  of  systam  control  implamantation,  tha 
prasanca  of  tha  I-S/A  AMPE(E)  within  tha  accass  araa  in  Architacturas  II 
and  III,  is  considarad  to  ba  an  advantaga  bacausa  it  parmlts  control 
functions  at  a lowar  laval  in  tha  natwork  than  Architactura  I.  Howavar, 
tha  dual  compaction  of  tha  I-S/A  AMPE  could  off sat  this  advantaga  in 
Architacturas  II  and  III  by  raqulrlng  mora  complax  accounting  and  con- 
trol functions.  Taking  all  thasa  factors  into  considaration,  Archi- 
tacturas II  and  III  ara  considarad  assantially  aqual  In  thalr  probabla 
parformanca  with  raspact  to  this  crltarlon.  Architactura  I is  con- 
sidarad to  ba  slightly  lass  dasirabla.  Tharafora,  tha  quality  point 
scoras  for  tha  altarnatlvas  as  a rasult  of  this  subcrltarlon  ara: 

Architactura  I - 1 point 

Architactura  II  - ♦ points 

Architactura  III  - ♦ points. 


(A)  Subcritarlon  »:  Systam  Motivatad  Functions.  Systam 
motivatad  functions  ara  thosa  functions  raqulrad  to  support  systam 
oparatlon  rathar  than  to  dlractly  provlda  usar  sarvlcas.  Typical  systam 
motivatad  functions  Includa  natwork  control  for  parformanca  assassmant 
and  status  monitoring,  accountability,  tachnlcal  control,  and  traffic 
control.  Tha  principal  dlffarancas  batwaan  architacturas  with  raspact 
to  this  subcrltarlon  rasult  from  dlffarancas  In  tha  dagraa  of  complaxlty 
raqulrad  to  daslgn  and/or  Implamant  tha  Mld-Tarm  IAS  systam  motivatad 
functions  for  aach  altarnativa  architactura.  In  ganaral,  tha  complaxlty 
of  tha  systam  Implamantation  In  this  araa  raflacts  tha  numbar  of  dlf- 
farant  typas  of  sarvica  alemants  as  wall  as  tha  total  numbar  of  alamants 
raqulrad  to  Implamant  tha  glvan  architactura.  Basad  on  tha  constraints 
astabllshad  In  Sactlon  II  of  this  raport,  tha  numbar  of  PSNs  will  ba 
Indapandant  of  tha  architactura  salactad.  In  addition,  slnca  tha  numbar 
of  I-S/A  AMPEs  will  ba  basad  upon  tha  usar  distribution,  tha  numbar  of 
I-S/A  AMPEs  can  ba  assumad  to  ba  aqual  for  all  thraa  altarnatlvas. 
Howavar,  slnca  tha  I-S/A  AMPE(E)  raplacas  axlstlng  I-S/A  AMPE  sltas  In 
Architactura  II,  this  altarnativa  will  raqulra  tha  smallast  total  numbar 
of  alamants  for  a glvan  laval  of  parformanca.  If  wa  assuma  that  tha 
numbar  of  CSFs  In  Architactura  I and  III  will  ba  basad  upon  tha  numbar 
and  distribution  of  usars,  than  tha  total  numbar  of  alamants  In  both  of 
thasa  altarnatlvas  will  ba  aqulvalant.  In  tarms  of  tha  numbar 


of  different  types  of  network  elements,  Architecture  II  has  an  advantage 
over  the  other  alternatives,  because  of  the  high  degree  of  commonality 
between  the  I- S/A  AHPE(E)  and  the  basic  I- S/A  AMPE.  Architecture  III  on 
the  other  hand,  with  both  a CSF  and  I-S/A  AHPE(E),  In  addition  to  the 
required  PSN  and  I-S/A  AMPE,  represents  the  largest  number  of  different 
types  of  elements  to  be  supported.  As  a result,  the  network  control 
functions  will  be  most  complex  In  Architecture  III,  least  complex  In 
Architecture  II,  and  somewhere  between  these  two  extremes  for  Architec- 
ture I.  Another  Important  consideration  pertinent  to  this  subcriterion 
Is  the  difficulty  of  maintaining  accountability  In  the  Mid-Term  IAS 
network.  In  this  regard.  Architectures  I and  II  have  an  advantage  over 
Architecture  III,  In  that  fewer  network  service  elements  would  be 
encountered  In  a typical  narrative/ record  transaction  flow  through  the 
network.  Additional  considerations  with  respect  to  this  subcriterion 
are  technical  control  and  traffic  control.  Architecture  I was  found  to 
have  a slight  advantage  over  the  other  two  alternatives  In  the  area  of 
technical,  control  since  the  technical  control  for  the  I-S/A  AMPE(E) 
contained  In  Architectures  II  and  III  would  be  somewhat  more  complex 
than  that  required  for  the  CSF  contained  In  Architecture  I.  No  signifi- 
cant difference  was  Identified  among  the  alternatives  In  the  area 
of  traffic  control  complexity.  Considering  all  of  the  above  factors, 
and  the  relative  strengths  and  weaknesses  of  each  alternative,  Alterna- 
tives I and  II  were  judged  to  be  approximately  equal  In  their  desira- 
bility with  respect  to  this  subcriterion.  Architecture  III  on  the  other 
hand  was  judged  to  be  somewhat  less  desirable  than  either  of  the  other 
two  alternatives.  Consistent  with  this  evaluation,  the  quality  point 
scores  for  this  subcriterion  are: 


Architecture  I 
Architecture  II 
Architecture  III 


4 points 
4 points 
1 point. 


(5)  Subcriterion  5:  Security.  The  security  functions  of  the 
Mid-Term  IAS  will  be  provided  by  a security  subsystem,  which  is  inte- 
grated Into  the  various  network  elements.  The  allocation  of  the  secur- 
ity subsystem  functions  and  the  operation  of  the  security  subsystem  will 
vary  depending  upon  the  architecture  selected.  In  order  to  evaluate  the 
alternative  architectures  with  respect  to  this  subcriterion,  a likely 
Implementation  of  the  security  subsystem  for  each  alternative  was  de- 
fined and  evaluated.  The  results  of  this  evaluation  are  presented  In 
detail  In  a separate  classified  appendix  (Appendix  E).  In  general,  the 
security  analysis  reveals  that  an  effective  security  subsystem  can  be 
Implemented  In  each  of  the  alternative  architectures.  As  a result,  the 
three  alternatives  are  ranked  equally  with  respect  to  this  subcriterion 
and  the  quality  point  assignment  Is  as  follows: 
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Architecture  I 
Architecture  II 
Architecture  III 


3 points 
3 points 
3 points. 


(6)  Subcriterion  6:  Adaptability  to  Oversees  Implementation. 
The  evaluation  of  the  alternative  architectures  with  respect  to  this 
subcriterion  concentrated  on  differences  among  the  alternatives  with  re- 
spect to  their  ability  to  support  Mobile  terminals  and  Mobile  network 
eleaients,  the  CONUS/Overseas  trunking  requirements  associated  with  each 
alternative,  and  the  risk  associated  with  overseas  deployment  of  the 
network  service  elements  used  In  each  architecture. 

In  comparing  the  ability  of  the  architectures  to  utilize 
mobile  or  transportable  elements  overseas,  the  required  network  element 
sizes  and  the  Impact  of  movement  of  elements  on  users  must  be  consid- 
ered. The  size  of  the  network  elements  Is  In  turn  determined  by  the 
functional  allocation  within  the  architecture  and  the  throughput  re- 
quirement of  the  network  elements  that  results  from  the  architecture 
hierarchy.  As  Indicated  In  the  network  element  acquisition  cost  analysis 
described  In  Appendix  C,  the  I-S/A  AMPE(E)  used  In  Architecture  II  1$ 
the  single  largest  element  used  In  any  architecture  based  on  both  func- 
tional allocation  and  communications  Interface  requirements.  This 
element  will  therefore  be  the  most  difficult  to  Implement  as  a mobile/ 
transportable  element.  In  addition,  since  the  I-S/A  AMPE(E)  used  In 
Architecture  II  also  terminates  a large  number  of  subscribers,  the 
Impact  of  moving  this  element  after  Initial  deployment  Is  significant. 

In  contrast,  the  CSF  used  In  Architecture  I 1$  almost  as  large  or  larger 
than  the  I-S/A  AMPE(E)  used  In  Architecture  II  from  the  standpoint  of 
functional  capability.  However,  because  the  CSF  In  Architecture  I In- 
terfaces only  to  a PSN  rather  than  to  many  subscribers,  and  Is  accessed 
via  the  network  rather  than  directly.  It  Is  much  more  amenable  to  re- 
deployment. Finally,  the  CSF  and  I-S/A  AMPE(E)  used  In  Architecture  III 
represent  the  smallest  network  element  size  because  the  functional 
requirements  are  approximately  evenly  divided  between  these  two  ele- 
ments. However,  the  potential  Impact  on  users  connected  to  the  I-S/A 
AMPE(E)  In  this  case  Is  the  same  as  for  Architecture  II.  Based  on  the 
offsetting  advantages  of  Architecture  I and  Architecture  III,  they  are 
judged  to  be  equally  desirable  with  respect  to  the  feasibility  of  mobile 
network  elements.  Architecture  II  Is  less  desirable  than  the  other  two 
alternatives  In  this  regard. 

In  terms  of  the  ability  to  support  mobile  terminals. 
Architecture  I Is  rated  slightly  more  desirable  than  the  other  two 
architectures.  This  results  from  the  concentration  of  all  network 
services  within  the  CSF  which  Is  accessed  via  the  network  by  all  users 
and  is  therefore  relatively  Insensitive  to  the  location  and  distribution 
of  users  at  any  time.  The  other  two  architectures  are  considered  to  be 
approximately  equal  In  this  regard. 


The  risk  of  overseas  deployment  of  network  elements 
cons 1 dors  tho  of foe t of  ovorsoas  deployment  on  network  vulnerability.  As 
a result  of  the  analysis,  no  significant  differences  among  architectures 
were  identified  In  this  area.  Similarly,  no  significant  difference  was 
found  In  the  requirement  for  CONUS/Overseas  trunking  between  the  three 
architectures.  As  a result  of  the  analysis.  It  was  determined  that  the 
CONUS/Overseas  trunklna  requirements  depend  primarily  upon  the  con- 
nection alternatives  within  architectures  and  whether  the  service  ele- 
ments are  located  overseas  along  with  the  PSNs. 

When  all  of  the  above  factors  are  taken  Into  account, 
Architecture  I was  judged  to  be  the  most  desirable  from  the  standpoint 
of  Its  ability  to  adapt  to  an  overseas  environment.  Architecture  III 
was  judged  to  be  the  next  most  desirable  architecture  for  overseas 
Implementation,  and  Architecture  II  was  judged  to  be  less  desirable  than 
either  of  the  other  alternatives.  Accordingly  the  quality  point  assign- 
ments with  respect  to  this  subcriterion  are: 

Architecture  I - 5 points 

Architecture  II  - 1 point 

Architecture  III  - 3 points. 


(7)  Summary  of  Evaluation  for  Operational  Effectiveness. 

The  results  of  the  evaluation  process  for  all  subcrlterla  within  this 
evaluation  criterion  are  summarized  In  Table  O-III.  As  Indicated  by 
this  table,  Architecture  I and  Architecture  II  are  essentially  equal 
with  respect  to  their  overall  operational  effectiveness.  Both  architec- 
tures are  clearly  preferred  to  Architecture  III  In  this  regard.  It  Is 
Interesting  to  note  that  In  all  respects,  except  for  transmission  effi- 
ciency and  adaptability  to  overseas  Implementation,  Architectures  I and 
II  are  judged  to  be  equally  desirable.  It  Is  also  Interesting  to  note 
that  Architecture  III  Is  judged  to  be  more  desirable  than  each  of  the 
other  alternatives  In  only  one  of  the  six  subcriteria. 


b.  Evaluation  Criterion  2:  Flexibility.  This  criterion  Is 
especially  Important  because  the  mid-term  architecture  must  be  flexible 
In  order  to  accommodate  changes  In  requirements  and  to  allow  continued 
evolution  throughout  the  mid-term.  Of  major  concern  is  the  Impact  of 
possible  Inaccuracies  In  the  current  estimates  of  the  number  of  sub- 
scribers, traffic  volume,  and  utilization  of  network  services.  As 
Indicated  In  Section  2,  architecture  evaluation  for  flexibility  focuses 
on  differences  between  alternatives  In  terms  of  both  adaptability  and 
expandability.  The  results  of  the  evaluation  process  for  each  sub- 
criterion within  this  category  are  presented  In  the  following  subpara- 
graphs. 


(1)  Subcrlterion  1:  Traffic  Type  Adaptability.  Ho  signif- 
icant differences  were  Identified  between  alternative  architectures  with 
raspact  to  this  subcritarion.  As  a result,  tha  quality  point  scoras  for 


this  subcriterion  are: 

• • » » 

Architecture  I 

• 

3 points 

Architecture  II 

- 

3 points 

Architecture  III 

m 

3 points. 

(2)  Subcritarion  2:  Ex tarns 1 Intarface  Adaptability.  Tha 
volume  of  traffic  directed  outside  tha  network  as  opposed  io  within  tha 
network  will  Impact  tha  nodal  traffic  flows  and  tha  loading  on  tha 
natwork  elements  Involvad  in  tha  gateway  function.  Since  in  aach  al- 
tarnativa  architecture  tha  gateway  function  Is  assigned  to  a single 
natwork  service  element  designated  as  tha  gataway  to  a particular  ex- 
ternal natwork,  no  significant  differences  between  alternatives  were 
Identified.  As  a rasult,  quality  point  scoras  for  this  subcritarion 


Architecture  I - 3 points 
Architecture  II  - 3 points 
Architecture  III  - 3 points. 


(3)  Subcritarion  3:  Natwork  Service  Adaptability.  Tha 
evaluation  of  alternatives  with  respect  to  this  subcritarion  concen- 
trated on  the  utilization  of  ASC  replacement  services  versus  new  ser- 
vices. Differences  between  architectures  In  this  regard  reflect  the 
differences  In  allocation  of  these  services  within  each  architecture. 

For  example,  Architecture  I provides  all  natwork  services  from  a single 
centralized  service  element  (i.e. , the  CSF).  If  the  CSF  is  designed  to 
permit  a reasonable  degree  of  load  sharing,  It  should  be  relatively 
Insensitive  to  variations  In  the  utilization  of  particular  services.  In 
addition,  since  individual  subscribers  are  not  allocated  to  a designated 
CSF  (homed),  there  is  an  additional  opportunity  for  load  sharing  among 
the  CSF  facilities  within  the  network.  Since  all  CSFs  are  accessed  via 
the  backbone  network,  this  network  load  sharing  should  not  significantly 
degrade  the  response  time  performance  of  the  network. 

Architecture  II  also  allocates  all  services  to  a single 
network  element  (I.e.,  the  I-S/A  AMPE(E)).  If  properly  designed.  It, 
too,  offers  the  advantage  of  nodal  load  sharing.  However,  since  some 
subscribers  are  connected  directly  to  the  I-S/A  AMPE(E)  and  some  are 
connected  via  an  I-S/A  AMPE  that  is  dual  connected  to  a PSN  and  an  I-S/A 
AR?E(E),  network  level  load  sharing,  while  possible,  is  somewhat  more 
complex  In  this  alternative.  For  example,  traffic  entering  the  network 
via  the  I-S/A  AMPE  that  requires  network  services  will  normally  be 
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routed  directly  to  the  connected  I-S/A  AMPE(E).  If  that  element  is 
unavailable,  however,  traffic  from  the  I-S/A  AMPE  can  be  routed  via  the 
connected  PSN  to  another  I-S/A  AMPE(E). 


1 


I 


Architecture  III  offers  approximately  the  same  degree  of 
network  level  load  sharing  as  Architecture  II  because  of  the  dual  con- 
nected I-S/A  AMPE  and  I-S/A  AMPE(E)  connected  subscribers.  However, 
because  the  network  services  are  split  between  two  network  service 
elements  (CSF  and  I-S/A  AMPE(E)) , this  architecture  does  not  offer  the 
same  degree  of  node  level  load  sharing.  As  a result  of  these  factors. 
Architecture  I is  considered  to  be  the  most  adaptable  to  changes  in 
demand  for  network  services  followed  by  Architecture  II  and  Architecture 
III,  in  that  order.  Accordingly,  the  quality  point  scores  with  respect 
to  this  subcriterion  are: 

Architecture  I - 5 points 

Architecture  II  - 3 points 

. Architecture  III  - 1 point. 


(4)  Subcriterion  4:  Subscriber/Traffic  Distribution 
Adaptability.  This  subcriterion  measures  the  sensitivity  of  the  system 
to  changes  in  the  day-to-day  distribution  of  traffic.  For  example, 
traffic  patterns  in  the  network  could  change  drastically  during  a 
crisis  situation.  Typical  perturbations  include  sudden  shifts  in  the 
ratio  of  local  versus  remote  traffic  or  significant  increases  in  the 
amount  of  traffic  in  a particualr  region.  Differences  between  alterna- 
tives with  respect  to  this  subcriterion  reflect  differences  in  the 
funtional  allocation  among  service  elements  as  well  as  differences  in 
the  user  access  to  these  services. 

Architecture  I is  considered  to  be  the  least  sensitive  to 
changes  in  subscriber  and  traffic  distribution  because  the  CSF  is 
accessed  via  the  backbone  by  all  subscribers.  In  fact,  it  is  likely  in 
Architecture  I that  a particular  subscriber  would  be  unaware  of  which 
CSF  was  providing  the  service  functions  for  any  given  transaction. 
Assuming  the  PSN  switching  nodes  and  trunks  were  properly  sized  to 
handle  the  worst  case  traffic  flows,  sudden  shifts  in  traffic  distribu- 
tion would  have  little  or  no  effect  on  overall  system  performance  in 
Architecture  I.  The  same  general  comments  apply  to  Architecture  III  but 
only  with  respect  to  the  new  network  services  provided  by  its  centralized 
CSF.  The  ASC  replacement  functions  allocated  to  the  I-S/A  AMPE(E)  in 
Architecture  III  and  all  network  service  functions  in  Architecture  II 
would  be  somewhat  more  sensitive  to  traffic  distribution.  Further,  it 
is  expected  that  during  the  mid-term  timeframe,  perturbations  are  more 
likely  to  occur  in  the  narrative/ record  traffic  (i.e. , the  ASC  replace- 
ment functions)  than  in  the  new  network  service  traffic.  Therefore, 
the  difference  between  Architectures  II  and  III  is  not  considered  sig- 
nificant. Finally,  it  must  be  remembered  that  the  virtual  message  pro- 
tocol (VMP)  and  the  dual  connection  of  the  I-S/A  AMPE  permit  most  single 
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address  narrative/record  traffic  to  be  exchanged  between  I-S/A  AMPE  con- 
nected subscribers  without  requiring  processing  by  the  higher  level 
service  elements  In  any  architecture.  Therefore,  the  basic  performance 
of  all  three  architectures  with  respect  to  this  subcriterion  will  be 
significantly  better  than  the  current  AUTOOIN  system. 

Taking  all  of  the  above  factors  Into  account.  Architec- 
ture I is  considered  to  be  the  most  desirable  alternative  with  respect 
to  this  subcriterion.  Architectures  II  and  III  each  are  considered  to 
offer  essentially  the  same  level  of  system  performance.  Accordingly, 
the  quality  point  scores  are: 


Architecture  I 
Architecture  II 
Architecture  III 


5 points 
2 points 
2 points. 


(5)  Subcriterion  5:  Subscriber  Expandability.  The  ability 
of  a system  to  expand  both  In  the  number  and  types  of  subscribers  is  a 
function  of  the  subscriber  termination  configurations  permitted  by  an 
architecture.  Since  each  alternative  provides  essentially  the  same 
subscriber  termination  alternatives  (i.e.,  PSN  connected  or  I-S/A  AMPE 
connected),  there  are  no  significant  differences  between  the  alterna- 
tives with  respect  to  this  subcriterion.  As  a result,  the  quality  point 
scores  are: 


Architecture  I 
Architecture  II 
Architecture  III 


3 points 
3 points 
3 points. 


(6)  Subcriterion  6:  Protocol  Expandability.  The  architec- 
tures were  compared  in  terms  of  their  ability  to  accoimnodate  new  user 
level,  network  level,  and  link  level  protocols  in  order  to  meet  evolving 
user  requirements.  The  introduction  of  new  user  level  protocols  and 
link  level  protocols  will  impact  subscriber  terminal  equipments  and, 
potentially,  the  I-S/A  AMPE  and  PSN  subscriber  Interfaces.  Since  these 
elements  are  common  to  all  three  alternatives,  no  significant  differ- 
ences between  the  architectures  were  identified  with  respect  to  link 
level  or  user  level  protocol  expandability.  Similarly,  new  network  level 
protocols  Involving  service  element- to- service  element  transfers  should 
have  an  equal  Impact  on  each  architecture.  A significant  difference 
between  alternatives  was  identified  in  terms  of  the  Impact  of  Introduc- 
ing new  user-to-servlce  protocols. 


In  Architecture  II  the  same  family  of  network  elements 
(i.e.,  I-S/A  AMPE  and  I-S/A  AMPE(E))  provides  both  network  services  and 
user  termination.  Therefore,  changes  in  the  user* to- service  element 
protocols  can  be  implemented  within  these  elements.  In  Architectures  I 
and  III,  however,  the  central  service  facility  does  not  terminate  sub- 
scribers directly.  Therefore,  changes  in  the  user-to-service  element 
protocols  could  Impact  both  the  I-S/A  AMPE  and  the  CSF.  During  the  mid- 
term timeframe,  It  Is  expected  that  new  user-to-service  element  proto- 
cols will  most  likely  be  Introduced  as  a result  of  the  new  network 
services.  Since  new  network  services  are  allocated  to  the  CSF  In  both 
Architecture  I and  Architecture  III,  no  significant  difference  Is  ex- 
pected between  these  two  alternatives.  As  a result,  Architecture  II  is 
considered  to  be  the  most  desirable  alternative  with  respect  to  this 
subcriterion.  Architectures  I and  III  are  both  considered  to  be  slight- 
ly less  desirable.  The  quality  point  scores  are: 


Architecture  I 
Architecture  II 
Architecture  III 


2 points 
5 points 
2 points. 


(7)  Subcriterion  7;  Service  Expandability.  This  subcri- 
terion refers  to  the  relative  impact  oT  adding  new  network  services  to 
the  Mid-Term  IAS.  Since  each  alternative  permits  the  same  degree  of 
implementation  options,  differences  between  architectures  with  respect 
to  adding  new  services  are  concentrated  on  the  degree  of  flexibility 
provided  to  the  system  designer  in  allocating  the  new  services  to  net- 
work elements.  As  a result,  Architecture  III  was  judged  to  be  the  most 
flexible  In  Its  ability  to  add  new  network  services  because  It  offers 
the  option  of  implementing  functions  In  one  of  two  network  service 
elements  (I.e.,  the  CSF  or  the  I-S/A  AMPE(E)).  No  significant  differ- 
ences were  Identified  between  Architecture  I and  Architecture  II. 
Therefore,  the  quality  point  scores  with  respect  to  this  subcriterion 
are: 


Architecture  I 
Architecture  II 
Architecture  III 


2 points 
2 points 
5 points. 


(8)  Subcriterion  8:  Control  Function  Expandability.  This 
subcriterion  measures  the  ability  of  the  system  to  accommodate  changes 
in  the  numbers  and  types  of  control  functions  used  in  the  network. 
Differences  among  alternatives  with  resoect  to  this  subcriterion 
result  from  differences  in  the  number  of  elements  and  the  number  of 
different  types  of  elements  contained  in  each  architecture.  These 
numbers,  in  turn,  affect  the  complexity  of  the  control  functions.  As 
discussed  previously  with  regard  to  system  motivated  functions,  Archi- 
tecture II  has  the  fewest  numbers  and  types  of  network  elements. 
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\ ‘ * As  a result,  tha  Implementation  of  new  control  functions  at  a future 

data  is  considered  to  have  less  Impact  on  Architecture  II  than  on  the 
other  architectures.  Accordingly,  the  quality  point  scores  with  respect 
to  this  subcriterion  are: 

Architecture  I - 2 points 

> C Architecture  II  * 5 points 

Architecture  III  - 2 points. 


(9)  Subcriterion  9:  Traffic  Expandability.  There  are  two 
primary  methods  available  to  increase  the  traffic  handling  capacity  of 

C the  network — Increase  the  number  of  service  elements  or  Increase  the 

size  of  the  existing  service  elements.  No  significant  differences  were 
Identified  between  the  architectures  In  terms  of  their  ability  to  add 
additional  service  elements  as  required.  In  terms  of  the  ability  to 
expand  the  size  of  existing  service  elements,  there  Is  a potential 
difference.  As  discussed  previously  with  regard  to  the  mobility  of 
< k service  elements  used  overseas,  the  I-S/A  AMPE(E)  used  In  Architecture 
II  has  the  highest  communications  throughput  of  any  service  element  used 
In  the  architectures.  Therefore,  the  upper  limit  of  memory  size  and/or 
processing  speed  In  the  I-S/A  AMPE(E)  may  be  reached  at  a lower  traffic 
volume  In  Architecture  II  than  In  the  other  architectures.  This  would 
require  the  Introduction  of  additional  service  elements  and  the  re- 
[c  distribution  of  subscribers  at  an  earlier  stage  of  growth.  Therefore 
Architecture  II  Is  somewhat  less  desirable  than  the  other  architectures 
with  respect  to  traffic  expandability.  Alternatively,  the  service  ele- 
ments In  Architecture  III  have  the  smallest  communications  throughput  of 
the  service  elements  used  In  the  architectures.  Consequently,  Archi- 
tecture III  can  be  expected  to  offer  the  highest  degree  of  flexibility 
c;  In  terms  of  service  element  expansion  versus  Introduction  of  new  service 
elements.  Accordingly,  the  quality  point  scores  with  respect  to  this 
subcriterion  are: 

[ 

Architecture  I - 3 points 

Architecture  II  - 1 point 

I t Architecture  III  - 5 points. 

(10)  Subcriterion  10:  External  Interface  Expandability. 

The  Interface  between  the  IAS  network  and  external  systems  may  be 
either  user  oriented,  as  In  the  case  of  all led/ tactical  Interfaces,  or 

; g network  oriented,  as  In  the  case  of  Interfaces  to  external  packet  net- 
works. The  optimum  allocation  of  gateway  functions  for  user  oriented 
external  systems  Interfaces  Is  to  a user  termination  element  such  as  the 
I-S/A  AMPE(E).  The  optimum  allocation  for  a network  oriented  external 
Interface  Is  to  a centralized  network  element  such  as  the  CSF.  Since 
Architecture  III  contains  both  the  I-S/A  AMPE(E)  and  the  CSF,  It  permits 
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the  optimum  expandability  with  regard  to  external  Interfaces.  Since  It 
Is  not  clear  at  this  time  whether  future  expansion  of  external  Inter- 
faces will  more  likely  Involve  user  oriented  or  network  oriented  sys- 
tems, Archltectues  I and  II  are  considered  equally  acceptable.  Con- 
sequently, the  quality  point  scores  with  respect  to  this  subcriterion 
are: 


Architecture  I- 
Architecture  II 
Architecture  III 


2 points 
2 points 
5 points. 


(if)  Summary  of  Evaluation  For  Flexibility.  The  results  of 
the  evaluation  process  for  all  subcHteHa  within  this  evaluation  cri- 
terion are  summarized  In  Table  D-IV.  As  Indicated  by  this  table, 
Architecture  I Is  the  least  sensitive  to  day-to-day  changes  In  the 
network  operation  because  of  its'  highly  centralized  structure.  Archi- 
tectures II  and  III,  on  the  other  hand,  are  more  easily  expanded  In  the 
future  to  accommodate  evolving  requirements.  As  a result,  each  archi- 
tecture provides  specific  advantages  with  respect  to  flexibility  and  no 
one  architecture  Is  clearly  preferred  over  the  others  overall. 

c.  Evaluation  Criterion  3:  Survlvablllty/Avai lability/ 
SupportablHty.  Survivability  is  a major  factor  in  the  selection  of  a 
Mid-Term  IAS  architecture.  Of  almost  equal  concern  Is  the  availability 
of  the  system  under  normal  conditions.  In  general,  the  factors  that 
affect  survivability  also  affect  availability.  Therefore,  the  evalua- 
tion of  alternative  architectures  concentrated  on  three  principal  sub- 
criteria: the  effect  of  failures;  the  ability  of  the  system  to  recover 
from  failures;  and  the  degree  of  failure  protection  Inherent  in  the 
architecture.  SupportablHty  Is  also  a major  factor  In  the  selection  of 
a Mid-Term  IAS  architecture.  One  of  the  principal  objectives  of  the 
Mid-Term  IAS  Is  to  reduce  the  operation  and  maintenance  costs  associated 
with  the  AUTOOIN  system.  The  three  factors  of  survivability,  availa- 
bility, and  SupportablHty  are  considered  together  as  one  evaluation 
criterion  because  factors  that  enhance  survivablllty/avallability  some- 
times adversely  affect  SupportablHty.  For  example,  distribution  of 
functions  among  a large  number  of  elements  can  tend  to  make  a system 
more  survlvable.  However,  the  resultant  redundancy  and  physical  dis- 
tribution of  hardware  and  software  can  also  significantly  Increase  the 
cost  of  maintaining  and  operating  such  a system.  The  results  of  the 
evaluation  process  with  respect  to  each  of  the  four  subcriteria  are 
presented  In  the  following  subparagraphs. 


(1)  Subcriterion  1:  Effect  of  Failures.  The  effect  on  the 
total  system  of  failures  In  Individual  elements  will.  In  large  measure, 
depend  upon  the  degree  of  redundancy  among  service  elements  and  com- 
munications facilities  provided  In  the  final  system  design.  As  a 


TABLE  D-IV.  EVALUATION  FOR  FLEXIBILITY 


result,  this  evaluation  concentrated  on  the  Inherent  differences  between 
architectures  In  terns  of  the  concentration  of  functional  capabilities 
and  subscriber  access  within  particular  service  elements  that  could 
result  In  "choke  points"  In  the  final  system  design  and,  hence,  ad- 
versely affect  survivability  and  availability.  As  a result  of  this 
analysis,  Architecture  II  was  Identified  as  having  such  a potential 
choke  point  In  the  form  of  the  I-S/A  AMPE(E).  As  noted  In  previous 
discussions,  the  I-S/A  AMPE(E)  In  Architecture  II  has  a high  communi- 
cations traffic  throughput  compared  to  the  service  elements  used  In  the 
other  architectures.  In  addition,  the  I-S/A  AMPE(E)  In  Architecture  II 
concentrates  both  network  service  functions  and  a significant  amount  of 
the  subscriber  termination  functions  within  a single  element.  There- 
fore, the  I-S/A  AMPE(E)  In  Architecture  II  represents  a potential  choke 
point  In  a stress  environment.  It  should  be  noted,  however,  that  even 
the  loss  of  an  I-S/A  AMPE(E)  In  Architecture  II  will  not  have  a cata- 
strophic effect  on  the  network  operation.  Since  the  I-S/A  AMPEs  which  may 
be  connected  to  the  I-S/A  AMPE(E)  will  be  dual  connected  to  a PSN, 
and  since  the  services  provided  by  the  I-S/A  AMPE(E)  can  also  be  pro- 
vided by  other  I-S/A  AMPE(E)  nodes  In  the  network,  only  those  subscri- 
bers singly  connected  to  the  I-S/A  AMPE(E)  Itself  will  experience  a loss 
of  service.  Remaining  subscribers  to  the  network  will  experience  only  a 
degradation  In  performance. 

As  a result  of  the  analysis,  It  was  determined  that  loss 
of  a CSF  or  I-S/A  AMPE(E)  In  Architecture  III  or  the  loss  of  a CSF  In 
Architecture  I would  have  relatively  equal  effect  on  overall  network 
operation.  As  a result,  the  quality  point  scores  assigned  for  this 
subcriterion  are  as  follows: 

Architecture  I - 4 points 

Architecture  II  - 1 point 

Architecture  III  - 4 points. 


(2)  Subcriterion  2:  Failure  Recovery.  The  user  level  and 
system  level  procedures  and  functions  required  to  recover  from  the  loss 
of  a link  or  node  In  each  architecture  were  analyzed.  In  general,  the 
procedures  required  to  recover  from  such  a loss  depend  upon  the  specific 
network  services  Involved  as  well  as  the  source  and  destination  locations 
and  the  subscriber  type.  Consequently,  no  significant  differences  In 
failure  recovery  capability  were  Identified  among  the  alternatives.  How- 
ever, an  Important  result  of  this  analysis  was  the  determination  that 
all  three  alternative  architectures  will  provide  significant  Improvement 
over  the  Near-Term  IAS  with  respect  to  their  ability  to  recover  from  the 
loss  of  a node  or  link.  For  example,  since  subscriber  terminal  equip- 
ments and  I-S/A  AMPE  equipments  are  not  dependent  upon  a designated 
(homing)  service  element,  the  ability  to  recover  from  loss  of  the  near- 
est service  element  Is  Inherent  In  the  routing  and  traffic  distribution 
capability  of  the  network.  Therefore,  no  special  procedures  are  required 


to  recover  fro*  th*  loss  of  any  single  service  element.  In  addition, 
tha  us*  of  th*  virtual  message  protocol  (VHP)  In  th*  I-S/A  AMPE  to  send 
nost  narratlv*/ record  Messages  provides  a significant  backup  to  the  more 
coaplex  Multiple  address  and  Message  processing  functions  provided  by 
the  higher  level  service  elements.  That  Is,  If  a CSF  or  an  I-S/A  AHPE(E) 
Is  lost,  a subscriber  connected  to  an  I-S/A  AMPE  could  still  send  mul- 
tiple address  messages,  on*  at  a time,  using  th*  VMP  without  assistance 
from  a higher  level  service  element.  Finally,  In  the  event  a desti- 
nation subscriber  Is  Inoperative  or  destroyed,  the  source  subscriber  can 
simply  readdress  th*  Message  either  manually  or  automatically  via  the  I- 
S/A  AMPE  and  forward  th*  message  to  a contingency  destination.  When 
these  features  are  used  singly  or  In  combination,  the  result  is  an 
alMost  continuous  graceful  degradation  from  complete  network  capability 
to  minimum  network  capability.  Since  the  same  features  are  available  In 
each  of  th*  three  alternative  architectures,  the  quality  point  scores 
with  respect  to  this  subcriterion  are: 

Architecture  I - 3 points 

Architecture  II  - 3 points 

Architecture  III  - 3 points. 


(3)  Subcriterion  3:  Failure  Protection.  Th*  degree  of 
failure  protection  provided  by  a given  architecture  is  a function  of  th* 
number  of  connection  alternatives  available  between  subscribers  and 
service  elements  and  the  degree  to  which  redundancy  can  be  added  to  th* 
network  after  Initial  Implementation.  Significant  differences  Identi- 
fied with  respect  to  these  two  factors  are  discussed  below. 

Both  Architectures  II  and  III  provide  considerable 
flexibility  In  terms  of  th*  number  of  ways  subscribers  can  be  multiply 
connected  to  the  network.  In  addition  to  the  preferred  configuration 
where  an  I-S/A  AMPE  Is  dual  connected  to  both  a PSN  and  an  I-S/A  AMPE(E) 

In  both  architectures,  the  I-S/A  AMPE(E)  will  be  dual  connected  to  two 
different  PSNs  In  most  cases.  Individual  subscribers  In  these  archi- 
tectures may  also  be  dual  connected  to  two  network  elements  of  th*  same 
type  depending  upon  th*  availability  of  adequate  communications  facili- 
ties. As  a result,  Architectures  II  and  III  offer  th*  possibility  of  a 
more  richly  connected  access  area  and,  hence,  greater  protection  against 
the  loss  of  any  single  communications  link  or  nod*  than  Is  available 
w4th  Architecture  I.  In  terms  of  th*  ability  to  Increase  redundancy 
after  Initial  Implementation,  Architectures  II  and  III  again  enjoy  an 
advantage  over  Architecture  1.  Since  any  I-S/A  AMPE  can  be  upgraded  to 
provide  I-S/A  AMPE(E)  capability  through  simple  addition  of  hardware/softwar* 
modules,  a high  degree  of  redundancy  Is  possible  In  Architectures  II  and 
III.  Further,  the  redundancy  of  th*  network  can  be  easily  Increased  In 
Incremental  stages  following  Initial  Implementation. 


Whan  all  thasa  factors  ara  takan  Into  account,  Archl- 
tacturas  II  and  III  ara  prafarrad  to  Architactura  I with  raspact  to 
failura  protaction  capabllltlas.  Accordingly,  tha  quality  point  scoras 
with  raspact  to  this  subcrltarlon  ara: 


Archltactura  I 
Archltactura  II 
Archltactura  III 


1 point 
4 points 
4 points. 


(4)  Subcrltarlon  4:  Supportabillty.  Tha  supportabillty  of 
tha  system  basad  on  archltactura  is  a function  of  tha  nuiabar  of  elements 
raquirad  to  Implement  a givan  leval  of  systaia  performance  and  tha  dagraa 
of  commonality  among  elements  within  tha  archltactura.  As  dlscussad 
pravlously,  Archltactura  II,  with  a singla  natwork  element  basad  on  tha 
already  daflnad  I-S/A  AHPE  family,  will  raqulra  tha  lowast  total  number 
of  elements  to  iaplaaant  a givan  natwork  capability.  This  factor,  along 
with  tha  high  dagraa  of  coaaonallty  batwaan  tha  I-S/A  AHPE(E)  and  tha 
I-S/A  AHPE,  aakas  a systaa  daslgn  basad  upon  Archltactura  II  tha  aost 
supportabla.  Altarnatlvaly,  Archltactura  III  with  its  CSF  and  I-S/A 
AMPE(E)  raquiras  tha  largast  nuabar  of  natwork  alaaants  to  iaplaaant  a 

?1van  natwork  capability.  In  addition,  tha  prasanca  of  two  distinct 
aalllas  of  aqulpaant  would  incraasa  tha  logistics  and  aalntananca  costs 
asscclatad  with  a systaa  basad  on  Archltactura  III.  Archltactura  I with 
a CSF  and  I-S/A  AHPE  would  raqulra  aora  alaaants  than  Archltactura  II 
but  fawar  than  Archltactura  III  to  iaplaaant  tha  saaa  natwork  capa- 
bllltias.  It  would,  howavar,  suffar  froa  tha  aalntananca  and  logistics 
difficulty  associatad  with  two  saparata  faallias  of  aqulpaant.  As  a 
rasult,  Archltactura  II  Is  cor.sidarad  to  ba  tha  aost  daslrabla  archl- 
tactura froa  tha  standpoint  of  supportabillty  followad  by  Archltactura  I 
and  III,  raspactlvaly.  Accordingly,  tha  quality  point  scores  wi*h  ra- 
spact to  this  subcrltarla  ara: 


Archltactura  I 
Archltactura  II 
Archltactura  III 


3 points 
5 points 
1 point. 


(5)  Suaaary  of  Evaluation  for  Survlvabillty/Avallablllt 


Tha  rasults  of  tha  avaluatlon  procass  for  all  sub- 
criceria  within  this  avaluatlon  crltarlon  ara  summarized  In  Tabla  D-V. 

As  Indlcatad  pravlously,  thara  Is  a clear  tradaoff  batwaan  survivability 
and  Maintainability.  This  Is  avldancad  clearly  with  raspact  to  Archl- 
tactura II.  Tha  consolidation  of  all  natwork  servlca  functions  in  a 
slnala  natwork  element,  tha  I-S/A  AHPE(E),  based  upon  tha  axlsting  I-S/A 
AHPE  family  of  equipments,  rasults  In  Archltactura  II  having  tha  lowast 
ranking  with  raspact  to  affact  of  falluras  and  tha  highast  ranking  with 
raspact  to  supportabillty.  Archltactura  III,  on  tha  othar  hand,  with 


TABU  IMT.  EVALUATION  TON  SURVIVABILITY/AVAILABILITY/SUPPONT ABILITY 


network  service  functions  distributed  across  a larger  number  of  elements 
tends  to  eliminate  potential  choke  points  or  concentrations  of  service 
and  user  access  while  Introducing  significant  logistics  and  maintenance 
difficulties.  Because  of  the  lower  level  of  connectivity  In  the  access 
region,  Architecture  I does  not  represent  a good  compromise  between 
these  two  extermes.  In  attempting  to  resolve  this  tradeoff,  significant 
weight  must  be  given  to  the  supportablllty  consideration.  As  evidenced 
In  the  earlier  discussions,  each  of  the  alternative  architectures  pro- 
vides a significant  Improvement  In  terms  of  survivability  over  the  near- 
term  IAS.  In  addition,  many  network  features  common  to  all  three  al- 
ternatives provide  graceful  degradation  and  tend  to  minimize  the  po- 
tential differences  In  this  area.  Supportablllty,  however,  remains  a 
driving  concern  for  the  mid-term.  Since  any  mid-term  architecture  will 
represent  a significant  Implementation  cost,  It  Is  Important  that 
considerable  attention  be  paid  to  operation  and  maintenance  costs  In 
order  to  optimize  the  life  cycle  cost  of  ownership  for  the  IAS  to  the 
DoO.  With  this  In  mind,  the  quantitative  advantage  of  Architecture  II 
over  the  other  alternatives  In  this  evaluation  category  takes  on  In- 
creased Importance  In  the  overall  selection  of  a Hld-Term  IAS  Archi- 
tecture. 


d.  Evaluation  Criterion  4:  Transition.  This  evaluation  cri- 
terion deals  with  the  relative  ease  (or  difficulty)  of  evolving  from  the 
Near-Term  IAS  to  a specific  mid-term  architecture  ard  beyond.  Accord- 
ingly, subscrlterla  were  defined  to  be:  the  degree  of  risk  Involved  In 
the  development  of  necessary  network  elements;  the  impact  of  the  transi- 
tion on  Near-Term  IAS  users  In  terms  of  continuity  of  service  and  In- 
creased/modified operational  procedures;  the  ease  of  Implementation  of 
the  necessary  network  elements;  and,  finally,  the  potential  for  evolu- 
tion to  a far-term  architecture.  Results  of  the  analysis  with  respect 
to  each  of  these  subcriteria  are  discussed  below. 


(1)  Subcriterion  1:  Development  Risk.  Because  the  state- 
of-the-art  of  available  technology  was  considered  as  a constraint  In  the 
definition  of  each  of  the  alternative  architectures,  and  because  the 
general  development  approach  for  the  Mid-Term  IAS  network  elements  has 
been  defined  by  OCEC,  differences  In  the  risk  of  successfully  developing 
the  necessary  harctoare  and  software  Implementation  of  IAS  network  ele- 
ments will  result  from  differences  In  the  number  of  different  develop- 
ment programs  that  must  be  managed,  funded,  and  controlled  In  order  to 
Implement  each  architecture.  Evaluation  with  respect  to  this  subcri- 
terion, therefore,  concentrated  on  evaluation  of  the  probability  of 
success  of  the  required  hardware  and  software  development  program(s). 
Recognizing  that  the  packet  switched  nodes  (PSN)  and  subscriber  terminal 
equipments  are  common  developments  to  all  three  alternatives,  Archi- 
tecture I requires  the  development  of  the  I-S/A  AMPE  and  the  CSF. 


Architecture  II  requires  the  development  of  the  I-S/A  AHPE  fully  of 
equipments  Including  the  I-S/A  AMPE(E).  Architecture  III  requires  the 
development  of  the  I-S/A  AHPE  fully  end  the  CSF.  Since  both  the  en- 
hanced end  basic  versions  of  the  IS/A  AHPE  fully  will  be  developed 
under  a single  progru,  and  since  the  probability  of  success  of  this 
single  development  progru  Is  considered  greater  than  the  combined 
probability  of  success  of  two  separate  developments.  Architecture  II  Is 
expected  to  Involve  the  lust  development  risk.  Because  of  the  high 
degree  of  commonality  within  the  I-S/A  AHPE  fully,  the  difference  In 
development  risk  between  the  two  programs  required  for  Architecture  III 
Is  not  considered  significant.  Accordingly,  the  assignment  of  quality 
points  with  respect  to  this  subcriterion  are: 

Architecture  I -2  points 

Architecture  II  - 5 points 

Architecture  III  - 2 points. 


(2)  Subcriterion  2:  User  Impact.  Mo  significant  differences 
were  Identified  between  the  architecture  alternatives  with  respect  to 
the  probable  Impact  on  current  users  of  the  transition  from  the  Near-Term 
IAS  to  the  Mid-Term  IAS.  As  described  In  Section  IV  of  the  body  of 
this  report,  the  transition  from  AHPE  to  I-S/A  AHPE  and  from  ASC  to 
I-S/A  AMPE(E)  or  CSF  should  not  result  In  significant  loss  of  continuity 
of  service  or  disruption  to  existing  user  operating  procedures.  There- 
fore, the  quality  point  scores  with  respect  to  this  subcriterion  are: 

Architecture  I - 3 points 

Architecture  II  - 3 points 

Architecture  III  - 3 points. 


(3)  Subcriterion  3:  Ease  of  Implementation.  The  probable 
complexity  of  Implementing  the  eld- term  architecture  with  respect  to 
each  alternative  Is  a function  of  the  number  of  network  service  elements 
that  must  be  Implemented  and/or  modified.  In  this  context  It  should  be 
remembered  thet  the  current  transition  planning  assumes  that  I-S/A  AHPE 
nodes  will  be  Implemented  as  a first  priority.  If  Architecture  II  Is 
selected  as  the  preferred  mid-term  architecture,  completion  of  the 
transition  process  will  require  only  the  enhancement  of  the  previously 
Installed  I-S/A  AHPE  nodes.  Architecture  I,  on  the  other  hand,  will 
require  Introduction  of  a totally  new  network  service  element  - the  CSF. 
Architecture  III  Implementation  will  require  Introduction  of  a CSF  and 
the  enhancement  of  existing  I-S/A  AMPEs  In  order  to  create  the  necessary 
I-S/A  AMPE(E)  nodes.  Additional  modifications  to  subscriber  terminal 
equipments,  operating  procedures,  remaining  ASCs,  AMPEs,  and  PSNs  will 
be  required  In  all  three  architectures.  As  a result.  Architecture  II  Is 


considered  to  be  the  best  of  the  three  alternatives  in  terms  of  imple~ 
mentation  of  the  mid-term  architecture,  followed  by  Architecture  I and 
Architecture  III,  respectively.  Consequently,  the  quality  point  scores 
with  respect  to  this  subcriterion  are: 

Architecture  I 3 points 

. Architecture  II  - 5 points 

Architecture  III  - 1 point. 


(4)  Subcriterion  4:  Potential  for  Evolution.  The  three 
alternative  architectures  were  evaluated  in  terms  of  their  potential  to 
evolve  towards  two  general  classes  of  future  IAS  architectures — a satellite 
backbone  architecture  and  an  integrated  voice  and  data  architecture. 

The  principal  differences  among  architectures  identified  as  a result  of 
this  analysis  result  from  the  allocation  of  network  service  functions  to 
the  access  area  versus  the  backbone.  Specifically,  Architecture  I was 
considered  somewhat  restrictive  to  evolution  to  the  two  potential  clas- 
ses of  far- term  architecture  because  of  the  role  of  the  CSF  and  its 
limitations  as  a backbone  element.  For  example,  retention  of  the  CSF  as 
the  primary  service  element  in  a satellite  backbone  architecture  could 
lead  to  multiple  satellite  hops  between  the  source  subscriber,  the  CSF, 
and  the  destination  subscriber.  Similarly,  the  implementation  of  an 
integrated  voice  and  data  network  is  likely  to  entail  additional  levels 
of  switching  within  the  access  area,  and  consequently  increase  the 
distance  between  the  subscriber  and  the  backbone  CSF  service  element. 

In  general,  therefore,  both  the  satellite  backbone  and  the  integrated 
voice  and  data  network  architectures  tend  to  favor  architectures  with 
services  provided  in  the  access  area,  closer  to  the  users.  As  a result, 
Architectures  II  and  III  provide  the  best  opportunity  for  continued 
evolution  from  the  mid-term  to  the  far-term.  Accordingly,  the  quality 
point  scores  with  respect  to  this  subcriterion  are: 

Architecture  I - 1 point 

Architecture  II  - 4 points 

Architecture  III  - 4 points. 


(5)  Summary  of  Evaluation  for  Transition.  Results  of  the 
evaluation  process  with  respect  to  all  four  subcHteria  within  this 
evaluation  category  are  presented  in  Table  0-VI.  As  indicated  in  this 
table.  Architecture  II  is  preferred  over  the  other  two  alternatives  in 
three  of  the  four  evaluation  subcriteria.  The  consolidation  of  all 
network  functions  in  a single  network  element  that  can  be  derived  from 
an  existing  R&O  program  allows  the  implementation  of  Alternative  II  in 
the  mid-term  with  minimum  development  risk  and  implementation  cost  and 
complexity.  In  addition,  the  location  of  all  network  functions  in  the 
access  area,  close  to  the  subscribers,  facilitates  the  eventual  imple- 
mentation of  both  satellite  backbone  and  integrated  voice  and  data 
architectures  at  a future  date. 


TABLE  D-VI.  EVALUATION  FOR  TRANSITION 


e.  Overall  Evaluation.  As  Indicated  In  Section  III,  the  evalua- 
tion methodology  consists  of  two  distinct  stages.  The  first  stage, 
qualitative  evaluation  and  the  assignment  of  quality  scores,  was  de- 
scribed In  the  preceding  paragraphs.  The  second  stage  of  the  process, 
calculation  of  an  overall  figure  of  merit  (FOM)  for  each  alternative 
architecture,  can  now  be  accomplished.  As  indicated  in  Section  III,  the 
overall  figure  of  merit  (F^)  is  calculated  by  summing  the  average  qual- 
ity point  score  derived  for  each  evaluation  criterion  (Q^)-  The  appro- 
priate values  of  Q^-  and  , calculated  from  the  evaluation  process,  are 

summarized  In  Table  D-VII.  As  Indicated  by  this  table,  Architecture  II 
receives  the  highest  overall  figure  of  merit  and  is  hence  preferred  over 
the  other  two  alternatives.  As  indicated  by  this  table.  Alternative  II 
is  clearly  preferred  in  the  areas  of  survivabllity/availability/supporta- 
bility  and  transition.  In  addition.  Architecture  II  is  evaluated  to  be 
almost  as  desirable  as  the  better  of  the  two  remaining  alternatives  in 
the  areas  of  operational  effectiveness  and  flexibility.  As  a result,  it 
is  unlikely  that  further  analysis  of  the  alternatives  would  reverse 
these  first  order  evaluation  results. 


As  discussed  In  Section  II,  one  of  the  principal  reasons  for 
calculating  the  overall  figure  of  merit  is  to  permit  the  application  of 
weighting  factors  to  the  evaluation  criteria.  In  order  to  determine  the 
Impact  of  weighting  on  the  evaluation  results,  a set  of  candidate  evalu- 
ation criteria  weights  were  defined  based  on  inputs  from  OCA.  These 
weighting  factors  are: 

Operational  effectiveness  - 1.5 
Flexibility  - 2.0 

Survivability/availability/supportability  - 3.0 
. Transition  3.5. 

These  weighting  factors  were  applied  to  the  quality  point  scores  derived 
from  Table  0-VII.  The  weighted  figure  of  merit  scores  that  result  from 
this  process  are:  v 

Architecture.  I - 27.4 
Architecture  II  - 35.6 
Architecture  III  - 27.7 

As  expected,  the  application  of  weighting  factors  does  not  change  the 
results  of  the  evaluation  process.  In  fact,  because  of  the  small 
numerical  difference  between  quality  point  scores  of  Architecture  II  and 
the  other  architectures  In  the  two  evaluation  criteria  for  which 
Architecture  II  is  not  clearly  preferred,  no  reasonable  weighting  of  the 
evaluation  criteria  would  change  the  principal  evaluation  results. 
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Basad  on  an  analysis  of  tachnlcal  factors,  altarnatlva  Archltactur# 
II  is  rtcomandad  as  tha  prafarrad  Mid-Tam  IAS  archltactura.  Basad  on 
its  slightly  hlghar  rating  than  Archltactura  I In  thraa  of  tha  four 
aval nation  crltarla,  Archltactura  III  Is  racoawandad  as  tha  first  al- 
tarnata. 


